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ABSTRACT 


This  thesis  describes  the  security  risks  for  network-centric  weapon  systems  as  a 
combination  of  different  aspects  of  security,  each  with  its  own  threats  and  mitigation 
strategies.  Computer  and  network  security  deals  with  cryptography,  authentication,  and 
attacks  on  software.  Information  security  deals  with  the  ability  of  the  system  to  process 
information  of  different  classifications  but  prevent  disclosure  to  unauthorized  users. 
Physical  security  ranges  from  hardware  destruction  to  reverse  engineering  of  captured 
hardware.  Operational  security  covers  the  inability  of  covert  units  to  transmit  to  the 
network  without  compromising  their  positions.  Personnel  security  discusses  the  ways 
that  people  can  intentionally  or  accidentally  weaken  the  system  during  development  or 
operations. 

Security  of  network-centric  weapon  systems  is  now  a  System  of  Systems  (SoS) 
engineering  problem  and  system  developers  must  therefore  embrace  a  systems 
engineering  approach  to  security  and  consider  all  the  threats  and  vulnerabilities  facing  the 
system.  This  examination  must  include  not  only  the  technical  characteristics  of  the 
components  but  also  the  people  who  operate  and  maintain  the  system  and  the 
requirements  of  the  mission.  Only  by  mitigating  the  most  efficient  attacks  on  the  system, 
regardless  of  the  type  of  attack,  can  developers  maximize  the  overall  security  of  the 
system. 
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I.  INTRODUCTION 


The  need  for  military  eommanders  and  units  to  eommunieate  with  eaeh  other  has 
existed  sinee  antiquity.  The  ereation  of  hierarchieally  organized  armies  led  eommanders 
to  realize  that  their  forees  fought  more  efficiently  when  concentrated  against  a  smaller 
force.  These  commanders  developed  tactics  to  flank  enemy  positions  and  deliver  a 
concentrated  attack.  Execution  of  these  tactics  required  the  commanders  to  maintain  an 
operational  picture  and  communicate  orders  to  their  units,  who  executed  the  orders  and 
reported  their  situations  back  to  the  commanders.  Communication  started  with  runners 
and  flag  signals,  evolved  into  radio  voice  messages,  grew  to  include  written  messages 
delivered  by  ground  or  satellite  radio,  and  finally  made  use  of  tools  like  the  U.S.  Navy’s 
Link- 16,  which  allows  real-time  sharing  of  both  friendly  and  enemy  position  data. 
Network-centric  weapon  systems  seek  to  provide  a  technological  and  tactical  leap  in  the 
efficiency  of  such  communication. 

A,  BENEFITS  AND  CHALLENGES  OF  NETWORK-CENTRIC  WEAPON 

SYSTEMS 

Network-centric  weapon  systems  seek  to  elevate  the  status  of  the  latest 
communication  tools  from  their  current  position  as  add-on  peripheral  gear  to  a  prominent 
role  as  a  critical  element  of  every  platform.  They  capitalize  upon  the  greater 
communication  capability  provided  by  computers  and  allow  every  unit  to  use  an 
operational  display  that  shows  the  sum  of  friendly  and  hostile  unit  positions  known 
across  the  entire  force.  The  availability  of  this  information  drives  a  paradigm  shift  where 
units  are  considered  nodes  in  a  network  rather  than  stand-alone  actors.  Most  units  serve 
as  both  users  and  providers  of  information,  while  stand-alone  sensors  serve  as  providers 
only  and  command  centers  serve  as  users  only. 

This  paradigm  shift  from  stand-alone  actor  to  network  member  has  its  greatest 
impact  upon  human  behavior.  Equipped  with  the  communications,  processing,  and 
interface  equipment  needed  to  provide  a  force-wide  situational  awareness  display,  the 
people  in  the  system  adapt  their  tactics,  behavior,  and  organization  to  take  full  advantage 
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of  their  new  awareness.  Commanders  use  a  more  complete  picture  of  the  action  to 
provide  subordinate  commanders  and  individual  units  with  general  combat  goals  instead 
of  specific  movement  orders;  operational  units  receive  these  goals  and  decide  for 
themselves  how  best  to  maneuver  and  strike  in  a  rapidly  changing  environment.  Units 
also  observe  the  status  of  both  friendly  and  enemy  forces  and  independently  adapt  their 
tactics  to  best  collaborate  with  friendly  forces.  This  self-synchronization  and 
collaboration  is  one  of  the  goals  of  network-centric  warfare  (Office  of  Force 
Transformation  2005). 

Another  goal  of  network-centric  warfare  is  to  make  the  command  process  faster 
and  more  robust.  The  powerful  communications  tools  inherent  in  a  network-centric 
system  allow  commanders  to  rapidly  send  situation  updates,  goals,  and  orders  to  the 
fighting  forces.  Provided  with  a  complete  operational  picture  and  the  set  of  combat 
goals,  subordinate  commanders  gain  the  ability  to  immediately  and  seamlessly  assume 
command  duties  when  the  original  commander  is  disabled.  The  automatic  sharing  of 
information  eliminates  the  need  for  lengthy  turnover  processes  between  the  departing  and 
relieving  commanders  and  greatly  reduces  the  chance  that  information  could  be  dropped 
during  the  transition  (Office  of  Force  Transformation  2005). 

Overall,  network-centric  systems  seek  to  lift  the  “fog  of  war”  and  provide  more 
efficient  use  of  forces.  When  every  ship,  plane,  vehicle,  and  infantry  or  special  forces 
group  knows  the  complete  picture  (the  location  and  tasking  of  all  friendly  forces,  the 
estimated  position  and  strength  of  enemy  forces,  and  the  set  of  combat  goals  and  progress 
made  toward  them),  well-trained  forces  can  apply  themselves  to  maximize  overall 
combat  effectiveness.  Implemented  properly,  the  use  of  network-centric  systems 
promises  greater  combat  power  provided  by  a  smaller  force  with  fewer  friendly  losses. 

Such  a  comprehensive  system  faces  serious  implementation  issues.  Shifting  to 

network-centric  warfare  requires  a  change  not  only  in  hardware  and  software  but  also  in 

doctrine,  organization,  training,  and  logistics.  Such  a  dramatic  shift  requires  time, 

probably  several  years  at  least,  to  accomplish.  The  problem,  then,  is  how  to  conduct 

operations  during  the  transition  period.  How  will  the  network-centric  units  coordinate 

their  movements  with  units  not  yet  converted?  How  will  commanders  lead  their  forces 
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when  the  network-centric  portion  expects  to  receive  goals  and  information  while  the 
legacy  platform-centric  portion  still  requires  specific  movement  orders  and  manual 
relaying  of  situational  awareness  information?  The  entire  premise  of  network-centric 
warfare  fails  when  major  parts  of  the  force  are  not  connected  to  the  network,  so  the 
upgraded  units  will  likely  be  forced  to  operate  as  legacy  units  until  the  entire  force  is 
converted. 

Even  after  the  total  conversion  of  U.S.  forces,  allied  and  coalition  partners  will 
remain  outside  the  network,  greatly  complicating  multi-national  operations.  Other 
nations  will  likely  have  an  incompatible  network  architecture,  if  they  have  one  at  all,  so 
U.S.  forces  will  again  have  to  revert  back  to  legacy  practices.  Given  that  the  transition  to 
network-centric  warfare  includes  sweeping  changes  in  doctrine,  operations,  and  training, 
this  devolution  back  to  legacy-style  operations  would  force  U.S.  units  to  fight  in  an 
unfamiliar  manner  and  without  the  benefit  of  their  training,  ensuring  lower  efficiency  and 
greater  friendly  losses. 

B,  SECURITY  RISKS 

In  addition  to  the  logistical  and  operational  challenges  of  transitioning  to  network¬ 
centric  warfare,  network-centric  weapon  systems  also  carry  major  security  risks.  The 
shift  to  a  network  paradigm,  where  each  unit  relies  upon  a  valid  connection  to  a 
functional  network,  means  that  a  successful  attack  upon  the  network  itself  can  degrade 
the  entire  force.  These  attacks  can  threaten  any  of  the  three  critical  features  of  an 
information  system:  confidentiality,  integrity,  and  availability  (Harris  2008,  59-61). 

Attacks  on  the  information  system  feature  of  confidentiality  threaten  to  expose  the 
entire  friendly  order  of  battle,  tactical  plans  and  goals,  and  knowledge  of  the  opposing 
force.  The  last  item  provides  perhaps  the  greatest  benefit  to  the  enemy  because  he  now 
knows  which  of  his  units  remain  undetected  and  available  for  a  surprise  assault.  An 
enemy  equipped  with  this  information  has  a  powerful  tactical  advantage  that  can  provide 
much  greater  effectiveness  for  his  forces,  which  are  now  able  to  attack  the  most 
vulnerable  parts  of  the  other  force  while  avoiding  detection  and  prosecution  of  their  own 
units. 
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Attacks  on  the  information  system  feature  of  integrity  threaten  to  sow  ehaos  into 
the  friendly  force,  even  if  few  modifieations  actually  get  made  to  its  database  of 
information  on  unit  positions,  mission  status,  and  sensor  data..  The  mere  pereeption  of 
tampering  would  destroy  eonfidenee  in  all  network-provided  information,  causing 
hesitation  in  taetieal  movement  and  a  flood  of  eommunieations  seeking  to  eonfirm 
position  reports  and  identity.  This  apprehension  among  the  friendly  foree  would 
eliminate  the  very  benefits  of  networked  systems,  self-synehronization  and  a  fast  and 
robust  eommand  element,  and  leave  paralyzed  units  vulnerable  to  hostile  maneuver. 
Even  worse  is  the  case  of  undeteeted  tampering,  where  the  enemy  ean  triek  friendly 
forees  into  firing  on  themselves  while  ehasing  false  contacts  and  operating  blind  to  real 
threats. 

Attaeks  on  the  information  system  feature  of  availability  represent  the  risk  with 
the  least  severity  but  greatest  likelihood.  A  friendly  foree  trained  and  organized  to 
operate  as  a  eohesive  whole  could  suffer  major  problems  if  suddenly  deprived  of  the 
network  and  foreed  to  operate  independently.  Enemy  attacks  can  disrupt  individual  unit 
connections  to  the  network  or  degrade  the  entire  network  itself  using  a  wide  array  of 
eomputer,  physieal,  and  eleetromagnetie  tools.  Eriendly  forees  eould  slide  into  hesitation 
and  paralysis  if  suddenly  foreed  to  operate  independently,  providing  an  assertive  enemy 
the  opportunity  to  bypass  friendly  defenses  and  strike  at  their  most  important  targets. 

Proteeting  the  seeurity  of  network-eentrie  weapon  systems  requires  eonsideration 
of  several  interrelated  aspeets:  eomputer  and  network  security,  information  security, 
physical  security,  operational  seeurity,  and  personnel  seeurity.  Attaekers  have  at  their 
disposal  a  broad  array  of  teehniques  to  disrupt  the  network,  so  developers,  maintainers, 
and  users  must  take  a  systems  engineering  approaeh  to  the  problem  of  defending  the 
network.  This  systems  engineering  approaeh  eonsiders  all  the  vulnerabilities  and  the 
possible  attaek  vectors  that  could  exploit  them  in  the  context  of  the  system’s  operational 
environment.  It  then  eonsiders  the  relative  efficieney  of  these  attaeks  and  applies 
defensive  resources  to  proteet  the  most  important  and  vulnerable  parts  of  the  network. 
Given  the  limits  of  funding  and  time  during  development,  developers  must  use  this 
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systems  engineering  approaeh  to  eounter  the  most  efficient  attacks.  The  efficiency  of  an 
attack  includes  its  ease  of  execution,  the  number  of  attack  opportunities,  and  the  amount 
of  damage  it  can  deliver. 

System  developers  have  two  primary  tools  to  ensure  the  security  of  the  network. 
First,  the  hardware,  software,  and  operating  procedures  must  be  developed  with  security 
as  a  primary  requirement.  Designing  the  network  to  meet  functionality  goals  and  then 
later  trying  to  build  in  security,  a  common  approach  in  the  commercial  world,  is  likely  to 
leave  serious  vulnerabilities  behind  (Schneier  2000,  395).  Flaws  will  remain  because  it  is 
impossible  to  envision  all  possible  attack  techniques  and  mitigate  them  and  because  some 
security  attacks  rely  on  weaknesses  in  the  system  architecture  itself.  The  design  must 
include  defense-in-depth  features  that  minimize  single  points  of  failure.  For  example,  a 
network  could  encrypt  its  communications  and  require  authentication  before  accepting 
any  messages,  so  an  attacker  who  manages  to  crack  the  encryption  scheme  and  send 
messages  on  the  network  would  also  have  to  figure  out  a  way  to  impersonate  a  legitimate 
network  user  and  spoof  the  authentication  process.  Second,  each  network  component  and 
the  overall  system  itself  must  be  subjected  to  rigorous  testing  and  certification.  This 
testing  includes  analysis  of  the  software  structure  and  coding,  hardware  examination,  and 
a  wide  range  of  scenarios  that  target  the  users,  interfaces,  and  other  aspects  of  the  system. 
Testing  alone  cannot  guarantee  the  security  of  any  complex  system,  but  it  can  at  least 
harden  the  system  against  the  easiest  and  most  damaging  attacks  (Schneier  2000). 

The  need  to  include  security  in  the  design  phase  of  the  system  extends  to  the 
entire  system  and  should  not  be  limited  to  the  hardware  and  software  design.  Network¬ 
centric  weapon  systems  are  systems-of-systems  (SoS),  so  the  security  architecture  must 
extend  to  each  individual  member  system  and  to  the  interface  to  the  overall  SoS.  Using  a 
rigorous  systems  engineering  approach  for  SoS  will  consider  all  the  threats  and 
vulnerabilities  and  reduce  the  risk  that  the  entire  system  could  be  easily  defeated  through 
a  previously  un-considered  attack  on  some  peripheral  part  of  the  system  (Office  of  the 
Deputy  Under  Secretary  of  Defense  for  Acquisition  and  Technology  2008).  This  effort 
must  include  not  only  the  technical  characteristics  of  the  components  but  also  the  people 
who  operate  and  maintain  the  system,  the  support  elements  that  keep  the  system  running, 
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and  the  environment  in  whieh  the  system  will  operate.  Onee  designed,  the  taeties, 
doetrine,  logisties,  and  personnel  elements  of  the  system  must  eontinue  the  systems 
engineering  approaeh  and  eonsider  seeurity  from  the  larger  system  perspective. 

The  systems  engineering  approach  must  also  extend  beyond  the  design  phase  into 
the  entire  system  life-cycle.  The  earliest  evaluation  of  technologies  and  doctrine  must 
include  the  need  for  an  inherently  secure  foundation  (Higginbotham  et  al.  1998).  For 
example,  the  Internet  and  its  supporting  protocols  were  designed  for  an  environment 
where  all  users  were  inherently  trusted,  so  use  of  these  protocols  may  inflict  military 
systems  with  the  same  security  problems  now  faced  by  commercial  and  industry  users 
(Harris  2008,  19-20).  During  the  operation  and  support  phase  of  the  system,  developers 
and  commanders  must  consider  the  security  risks  that  can  come  from  operators, 
maintainers,  and  administrators  and  the  consequences  of  deviating  from  security  rules. 
This  thesis  will  guide  those  developers  and  commanders,  as  well  as  operators  and  other 
stakeholders,  in  the  acquisition  and  design  of  secure  network-centric  weapon  systems. 

This  thesis  makes  a  distinction  between  the  computerized  systems  comprising  a 
network-centric  weapon  system  and  the  computer  networks  already  in  widespread  use  for 
office  automation,  collaboration,  and  communication.  Most  scholarship  on  computer 
security  focuses  on  the  latter  type  of  system.  These  systems — the  ones  using  x86-based 
processors  from  Intel  or  AMD,  Windows  or  Unix-based  operating  systems,  and  TCP/IP 
connections  to  the  global  internet — form  the  foundation  for  commerce,  education,  and 
entertainment  (Comer  1999).  They  experience  regular  security  attacks  from  people 
seeking  to  commit  fraud,  steal  proprietary  information,  or  knock  a  website  out  of  service 
(Schneier  2000,  1-5).  Their  components,  being  designed  for  widespread  and  general- 
purpose  use,  are  inherently  open  to  anonymous  members  of  the  public  and  must  be 
hardened  to  prevent  unauthorized  access  or  malicious  operations.  Service-oriented 
architectures  used  for  military  purposes  fall  into  this  category  and,  although  they  share 
many  of  the  security  risks  with  network-centric  weapon  systems,  they  inherit  the 
additional  concerns  faced  by  commercial  networks. 
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Network-centric  weapon  systems,  the  focus  of  this  thesis,  may  evolve  from  a 
collection  of  special-purpose  hardware  and  software,  such  as  the  LINK- 16  tactical  data 
link,  that  inherently  rejects  unauthorized  access  and  malicious  operations  (Camana  2009). 
Its  operators  will  be  trained  in  proper  and  secure  operation  and  will  be  accountable 
members  of  the  military.  Even  though  the  stakes  may  be  higher  with  a  weapon  system 
than  an  office  network,  the  developers  may  find  it  easier  to  secure  the  weapon  system 
because  of  its  limited  scope  and  rigorous  configuration  management.  Many  of  the  same 
security  principles  still  apply,  however,  and  much  of  the  work  done  to  secure  office 
systems  can  inform  the  development  of  weapon  systems’  security.  These  commercial 
practices  become  especially  relevant  if  the  network-centric  weapon  systems  are 
constructed  from  the  same  commercial  hardware  and  software  components  as  the  office 
networks,  which  may  be  necessary  in  order  to  keep  the  cost  down  and  the  schedule  short 
enough  to  be  deployable  (Commission  on  Physical  Sciences,  Mathematics,  and 
Applications  2000,  176). 

C.  EXAMPLE  SYSTEMS 

Network-centric  weapon  systems  recently  in  development  include  the  U.S. 
Army’s  Future  Combat  System  (ECS)  and  the  Navy’s  Cooperative  Engagement 
Capability  (CEC).  Both  systems  illustrate  the  emergence  of  a  new  class  of  networked 
system.  This  new  class  is  a  hybrid  of  the  office  automation  network  and  the  data-linked 
combat  system,  and  it  requires  a  consideration  of  security  principles  tailored  to  its 
combined  lineage.  Developers  must  avoid  both  the  blunt  misapplication  of  inappropriate 
office-network  security  controls  and  the  assumption  that  the  system  has  no  security  risks 
due  to  its  combat  system  characteristics. 

The  ECS  as  originally  envisioned  in  Figure  1,  combined  ground  vehicles, 
unmanned  aerial  vehicles  (UAVs),  and  remote  ground  sensors  into  a  single  network. 
This  network  was  to  provide  mission  planning,  situational  awareness,  and  tactical 
coordination  to  operators  and  commanders.  The  vehicles  included  tanks,  personnel 
carriers,  mortars,  cannons,  command  units,  medical  platforms,  and  unmanned  units 
optimized  for  attack,  reconnaissance,  and  logistics.  Four  types  of  UAVs  and  two  types  of 


7 


unattended  ground  sensors  were  to  provide  sensor  data  without  risking  harm  to  personnel 
(Globalseeurity.org).  Due  to  cost  and  schedule  problems,  the  Army  has  significantly 
revised  and  reduced  the  scope  of  the  PCS  program;  however,  some  elements  may  yet 
emerge  as  deployable  systems.  Future  weapon  systems  will  probably  inherit  the 
network-centric  philosophy  of  PCS,  so  the  original  program  serves  as  a  useful  example  of 
a  generic  network-centric  weapon  system  of  the  future.  This  shift  toward  a  network¬ 
centric  weapon  system  will  likely  continue  even  with  the  shift  in  emphasis  to  counter¬ 
insurgency  operations.  Army  Colonel  John  Buckley,  a  strategic  planner  for  the 
Headquarters  of  the  Department  of  the  Army,  said,  “Indeed,  there  is  a  strikingly  high 
correlation  between  the  types  of  capabilities  that  commanders  in  Iraq  and  Afghanistan  are 
requesting  and  the  types  of  capabilities  that  are  being  developed  through  PCS”  (Osborne 
2009). 
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Figure  1 .  Future  Combat  Systems  components  (From  Defense  Industry  Daily  2008) 


The  CEC  provides  a  smaller  example  of  a  network-centric  weapon  system.  CEC 
gives  ships,  planes,  and  air  defense  units  the  ability  to  share  their  radar  sensor 
information  and  create  a  single,  fused  radar  air  track  for  each  target.  This  sharing  and 

fusing  of  sensor  data  allows  all  units  to  observe  and  react  to  any  air  target  spotted  by  any 
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friendly  unit  that  is  connected  to  the  network.  It  also  improves  track  accuracy  by  giving 
increased  weight  to  the  data  reported  from  more  accurate  radars  (O’Neil  2007,  14). 
These  functions  of  CEC  are  shown  in  Figures  2,  3,  and  4.  This  application  of  network¬ 
centric  philosophy  provides  only  the  situational  awareness  function  for  air  contacts  and 
includes  no  functions  for  status-sharing  or  command  functions;  however,  it  does  provide 
a  low-cost  way  to  explore  new  tactics  and  find  the  best  new  capabilities  to  include  in 
future  systems. 
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The  enormous  eost  and  seope  of  the  Army’s  PCS  illustrate  the  eomplexity  of 
network-eentrie  weapon  systems  and  the  diffieulty  of  implementing  them  properly. 
Seeurity  is  eostly,  and  as  Department  of  Defense  (DoD)  policy  urges  developers  to 
pursue  the  “good  enough”  solution  and  to  save  money  by  stopping  short  of  the  perfect 
solution  (Dudney  2009,  2),  developers  risk  catastrophic  failure  of  the  fielded  systems  if 
they  avoid  the  rigorous  design  and  analysis  needed  to  provide  that  security. 

D,  OTHER  STUDIES  ON  THIS  TOPIC 

Network-centric  weapons  systems  are  System  of  Systems  (SoS)  that  require  a 
systems  engineering  approach  to  their  security  considerations.  Therefore,  few  studies 
exist  on  security  as  specifically  applied  to  network-centric  weapon  systems.  Discussions 
on  computer  system  security  for  home,  commercial,  and  industrial,  and  non-tactical 
military  purposes  dominate  the  literature.  Many  of  the  principles  of  these  works  on 
commercial-type  security  do  apply  to  weapon  systems,  particularly  those  built  from 
commercial  hardware,  software,  and  protocols,  but  tactical  use  brings  some  unique 
security  risks  that  this  thesis  will  enumerate.  Three  studies  of  note  include  a  2004  report 
titled  “Issues  and  Requirements  for  Cybersecurity  in  Network-centric  Warfare”  by  Drs. 
Stytz  and  Banks  of  the  Air  Force  Research  Laboratory;  a  book  published  in  2000  by  the 
Commission  on  Physical  Sciences,  Mathematics,  and  Applications  titled  Network-Centric 
Naval  Forces:  A  Transition  Strategy  for  Enhancing  Operational  Capabilities',  and  a  study 
underway  by  the  Naval  Studies  Board  titled  “Information  Assurance  for  Network-Centric 
Naval  Forces.” 

The  Air  Force  Research  Laboratory  report  focused  on  computer  and  network 
security,  describing  both  as  attacks  on  software.  The  report  provided  technical  details  on 
these  software  attacks  but  did  not  consider  the  other  sources  of  security  risks  covered  in 
this  thesis.  The  authors  describe  their  vision  as  follows: 

Our  vision  for  network  centric  warfare  cyber  security  can  briefly  be 
described  as  calling  for  a  seamless  web  of  protection  technologies  for  all 
levels  and  all  portions  of  the  network  and  software.  The  protection 
capabilities  (and  needs)  range  from  data  to  network  to  software  with  all 
components  being  imbued  with  inherent  capabilities  to  verify  their  own 
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correct  and  secure  operation  as  well  as  the  correct  and  secure  operation  of 
the  other  interacting  components  of  the  cyber  battlespace.  (Stytz  and 
Banks  2004,  4) 

The  book  from  the  Commission  on  Physical  Sciences,  Mathematics,  and 
Applications  (part  of  the  National  Research  Council)  provides  a  detailed  and 
comprehensive  examination  of  the  entire  field  of  network-centric  warfare.  The  chapter 
on  Information  Assurance  includes  such  non-traditional  risks  as  the  espionage  and 
sabotage  threat  during  development,  the  vulnerabilities  inherited  from  commercial 
hardware  and  software,  and  the  danger  of  enemy  eavesdropping  and  spoofing  using 
captured  hardware.  The  book  embraces  the  systems  approach  to  implementation, 
operations,  and  security,  and  provides  an  excellent  companion  to  this  thesis  despite  its 
focus  on  the  Navy  and  Marine  Corps.  This  thesis  provides  more  of  a  systems  engineering 
perspective  as  well  as  consideration  of  aspects  such  as  operations  security  not  covered  in 
the  book. 

The  Naval  Studies  Board  project  commenced  in  January  2008  and  was  planned  to 
be  a  twelve-month  study.  The  project’s  goals  include  an  analysis  of  studies  on 
information  assurance,  an  evaluation  of  the  acquisition  process  with  respect  to 
information  assurance,  an  assessment  of  security  vulnerabilities,  and  development  of  best 
practices.  The  project  duration  was  extended  to  June  30,  2009;  however,  as  of  this 
writing,  no  reports  have  yet  been  released  and  the  website  for  the  National  Academies 
still  lists  it  as  a  current  project.  These  reports  are  likely  to  provide  useful  information  on 
the  topic,  though  it  is  not  evident  whether  the  Board  will  have  taken  the  systems  approach 
or  will  have  focused  on  technical  aspects  only. 

E,  PURPOSE  OF  THIS  THESIS 

This  thesis  will  evaluate  the  most  important  security  risks  and  requirements  in  the 
design  of  network-centric  systems  and  services.  To  accomplish  this,  it  will  describe  the 
difference  between  network-centric  and  stand-alone  systems  and  consider  how  security 
for  a  network-centric  system  differs  from  commercial  computer  security.  It  will 
summarize  the  attack  methods  of  concern,  describe  how  these  attacks  can  gain  access  to 
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systems,  and  explain  the  eonsequenees  of  sueeessful  attacks.  It  will  recommend  features 
and  practices  to  reduce  the  security  risk  and  discuss  the  DoD  requirements  for  testing  and 
certification  that  enforce  the  use  of  security  features. 

This  examination  of  security  considerations  for  network-centric  weapon  systems 
will  help  guide  the  acquisition  process  for  network-centric  and  Service  Oriented 
Architecture  systems.  It  will  evaluate  the  current  DoD  security  directives  and  their 
applicability  to  network-centric  weapon  systems.  It  will  also  provide  source  material  for 
use  in  the  development  of  Naval  Postgraduate  School  resident  and  certificate  courses  on 
network-centric  system  development. 

In  this  thesis,  the  following  Chapters  II-VI  describe  the  various  aspects  of 
security  most  likely  to  factor  into  the  design  of  network-centric  weapon  systems: 
computer  and  network  security,  information  security,  physical  security,  operational 
security,  and  personnel  security.  Chapter  VII  provides  information  on  combining  these 
disparate  elements  into  an  optimized  system  solution  that  provides  the  greatest  security 
for  the  lowest  cost.  Chapter  VIII  provides  an  overall  conclusion. 
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II.  COMPUTER  AND  NETWORK  SECURITY 


This  chapter  on  computer  and  network  security  deals  with  technologieal  attacks 
against  the  execution  of  code  and  the  transmission  and  storage  of  data.  Since  network- 
eentrie  systems  will  be  highly  eomputerized,  this  part  of  system  security  captures  the 
greatest  share  of  attention  and  resourees  both  by  industry,  as  suggested  by  the 
preponderance  of  literature  on  the  subject,  and  by  this  thesis.  It  also  presents  the  greatest 
engineering  challenge  since  the  problems  and  solutions  foeus  on  teehnical  aspeets  of 
system  operation  rather  than  the  operational  and  procedural  aspects  dealt  with  in  other 
parts  of  system  seeurity. 

The  fundamental  security  challenge  at  the  heart  of  any  computerized  system  is 
one  of  abstraction.  Levels  of  abstraetion  include  the  network  level,  eomponent  level,  and 
others  depending  upon  the  speeific  design.  Computers  do  exactly  as  commanded  by  their 
programming  and  processor  design,  but  users  have  almost  no  insight  about  the  actual 
operations  taking  plaee  within  the  microproeessors,  memory  chips,  and  other  hardware. 
Users  typieally  only  see  the  user  interface,  which  represents  only  a  vague  abstraction  of 
the  billions  of  operations  per  second  acting  upon  the  billions  of  bytes  of  data  and 
instructions  in  a  typical  computer.  As  noted  seeurity  expert  Bruce  Sehneier  stated. 

People  don’t  understand  eomputers.  Computers  are  magieal  boxes  that  do 
things.  People  believe  what  computers  tell  them.  People  just  want  to  get 
their  jobs  done.  (Sehneier  2000,  255) 

The  seeurity  risk  here  is  that  the  user  interface  reports  only  what  it  is  eommanded  to 
report  by  the  underlying  application,  not  the  actual  series  of  events.  Computers  can  lie 
just  as  easily  as  they  can  tell  the  truth,  and  users  have  few  ways  to  find  the  lies. 

Attaekers  eapitalize  upon  the  enormous  complexity  of  computer  operations  that 
requires  sueh  a  profound  abstraction  in  order  to  communicate  with  users.  Simple 
programs  in  simple  systems  have  few  opportunities  for  attaekers  to  interfere  with  this 
trusted  user-computer  relationship;  unfortunately,  any  system  that  meets  the  extensive 
requirements  of  a  network-centrie  military  force  would  be  complex  and  therefore 
vulnerable.  System  designers  ean  establish  a  seeurity  arehitecture  that  reduees 
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complexity  by  defining  diserete  proeess  and  data  elements  and  their  interfaees,  redueing 
the  number  of  entry  points  for  an  attaek.  Sueh  a  design  follows  the  software  engineering 
prineiples  of  loose  eoupling  and  high  eohesion  (Larman  2006). 

Attaeks  on  the  eomputer  network  ean  threaten  that  system’s  eonfidentiality, 
integrity,  and  availability.  Confidentiality  attaeks  involve  reading  seeret  information  by 
intereepting  network  eommunieations  or  by  implanting  eode  that  grabs  seeret  data  and 
leaks  it  to  the  enemy.  Integrity  attaeks  involve  the  injeetion  of  false  information  into  a 
trusted  network  link  or  the  direet  alteration  of  data  stored  within  the  system.  Availability 
attaeks  involve  the  interruption  of  the  system’s  operations  or  its  ability  to  eommunieate. 
Some  attaek  teehniques  eombine  these  three  elements  and  ean  be  used  to  produee  a  wide 
variety  of  effeets  and  extensive  damage  (Committee  on  National  Seeurity  Systems  2006). 

A,  ATTACKS  ON  THE  NETWORK 

Outsiders  wishing  to  attaek  a  network-eentrie  system  generally  start  by  attaeking 
the  eommunieations  between  network  nodes.  The  simplest  type  of  network  attaek, 
jamming,  relies  upon  the  faet  that  a  taetieal  military  network  would  use  eleetromagnetie 
transmissions  to  send  most  of  its  information.  Jamming  has  been  praetieed  for  deeades, 
and  it  simply  involves  the  radiation  of  eleetromagnetie  noise  on  the  same  earrier 
frequeney  in  use  for  oommunieation.  Sophistieated,  modem  jammers  ean  silently  listen 
for  transmissions  and  quiekly  send  bursts  of  energy  at  a  matehing  frequeney,  eutting  off 
whatever  message  the  target  system  intended.  Jamming  intends  to  dismpt  the  availability 
of  the  system  by  making  it  impossible  for  network  nodes  to  eommunieate  with  eaeh 
other. 

Anti-jam  teehniques  have  also  evolved  over  the  years,  and  they  often  involve 
spread-speetmm  transmissions  with  error  deteetion  and  eorreetion  (Anderson  2008,  567- 
72).  Spread-speetmm  transmissions  involve  rapid  ehanges  in  the  earrier  frequeney  (about 
77  thousand  times  per  seeond  in  the  ease  of  Link- 16),  foreing  the  attaeker  to  spread  the 
jamming  energy  over  a  broad  range  of  frequeneies  and  therefore  redueing  the  jamming 
effeet  on  any  given  frequeney  (Carmana  2009,  1 -AM-62).  The  frequeney  seleetion  for 
the  next  hop  relies  upon  some  seeret  data  shared  among  the  network  nodes,  denying  the 
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enemy  the  ability  to  prediet  the  next  frequeney.  Interleaving,  the  re-arranging  of  data  bits 
within  a  message,  ean  be  used  with  error  deteetion  and  eorreetion  algorithms  sueh  as 
Hamming  eodes  or  Reed-Solomon  eodes  to  provide  redundaney  in  the  data  stream  that 
allows  the  reeeiver  to  reeonstruet  a  message  eontaining  a  small  number  of  missing  or 
flipped  bits  (Carmana  2009,  2-AM-80).  In  addition,  several  adaptive  fdtering  teehniques, 
sueh  as  noteh  filtering,  adaptive  beamforming,  nonlinear  adaptive  filters,  ete.  have  been 
developed  for  anti-jam  applieations  (Haykin  2002). 

Outsiders  ean  also  attaek  the  eonfidentiality  of  the  target  system  by  eavesdropping 
on  network  eommunieations.  Assuming  no  seeurity,  eleetromagnetie  transmissions  ean 
be  reeeived  by  friend  and  foe  alike,  so  attaekers  need  only  to  have  a  reeeiver  tuned  to  the 
eorreet  frequeney  and  plaeed  in  the  same  geographie  area.  The  needed  size  and  design  of 
this  reeeiver  and  the  proximity  to  the  transmitter  depend  upon  the  transmission  frequeney 
and  power  as  well  as  terrain  eharaeteristies.  Landline  eommunieations  ean  be  observed 
through  the  use  of  a  eable  tap.  These  taps  ean  physieally  penetrate  the  eable,  for 
eleetrieal  or  optieal  eables,  or  ean  measure  eleetromagnetie  induetion  for  eleetrieal  eables 
only  (Anderson  2008,  530).  Proteeting  against  eavesdropping,  therefore,  eannot  rely 
upon  denying  the  enemy  the  ability  to  reeeive  and  eopy  transmissions. 

Proteetion  against  eavesdropping  must  use  eneryption  to  disguise  the  true  eontent 
of  friendly  transmissions.  Eneryption  has  been  in  use  for  thousands  of  years  and  has 
exploded  in  eomplexity  sinee  the  appearanee  of  the  eomputer,  but  the  two  fundamental 
elements  have  remained  the  same:  the  key  and  the  algorithm.  The  key  is  simply  a  string 
of  data  shared  in  seeret  among  the  network  nodes.  The  algorithm,  or  eipher,  is  the  set  of 
proeedures  for  altering  the  message,  or  plaintext,  and  turning  it  into  eiphertext  that  ean 
only  be  deeoded  by  someone  who  also  possesses  the  same  key  and  algorithm  (Harris 
2008,  666). 

Keys  eome  in  two  forms,  symmetrie  and  asymmetrie.  Symmetrie  keys,  together 

with  an  appropriate  eipher,  perform  both  eneryption  and  deeryption.  They  operate  simply 

and  quiekly  but  require  the  seeure  distribution  of  keys  in  advanee.  They  also  require 

separate  keys  for  every  needed  eombination  of  partieipants  sinee  anyone  with  the  key  ean 

read  the  eonversation.  Asymmetrie  keys  exist  as  matehed  pairs  of  keys,  with  one  key 
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performing  encryption  and  the  other  key  of  the  pair  performing  decryption.  Users  keep 
one  key  private  and  publish  the  other  one  for  other  network  members  to  use.  Asymmetric 
encryption  is  much  slower  and  more  complex,  but  it  requires  no  advance  key  distribution 
and  requires  only  one  key  pair  for  each  node  (Harris  2008,  679-83). 

Ciphers  use  a  combination  of  substitution,  transposition,  and  other  mathematical 
manipulation  to  achieve  the  desired  degree  of  confusion  and  diffusion  in  the  ciphertext. 
Substitution  involves  replacing  one  character  for  another  and  is  popular  in  one-time-pad 
ciphers,  where  the  key  is  the  same  length  as  the  message  and  messages  are  often  encoded 
and  decoded  by  hand.  Transposition  involves  shuffling  the  order  of  the  characters, 
similar  to  a  word-scramble  puzzle  (Harris  2008,  679).  Confusion  refers  to  making  the 
relationship  between  the  key  and  the  ciphertext  as  complex  as  possible,  and  diffusion 
refers  to  making  the  relationship  between  the  plaintext  and  the  ciphertext  as  complex  as 
possible.  Together,  they  ensure  that  small  changes  to  the  key  or  plaintext  result  in  large 
changes  to  the  ciphertext,  making  it  difficult  for  an  attacker  to  crack  the  code  (Shannon, 
1946,  708-709). 

Computer-based  ciphers  tend  to  operate  at  the  bit  level  instead  of  the  character 
level  of  ancient  ciphers,  so  more  complex  mathematical  operations  become  available. 
Many  ciphers  use  the  “exclusive  or”  as  a  fast  and  reversible  way  to  encrypt  a  data  string 
according  to  the  key.  Complex  ciphers  borrow  the  concepts  of  substitution  and 
transposition  by  applying  them  to  blocks  of  data  and  then  sometimes  chaining  these 
blocks  together  and  using  the  ciphertext  from  one  block  to  form  a  new  key  for  the  next 
block  (Harris  2008,  685-7).  Ciphers  for  asymmetric  keys  can  rely  upon  such  irreversible 
operations  as  modular  arithmetic  (taking  the  remainder  of  a  division  operation)  to  ensure 
that  an  enemy  cannot  decrypt  the  ciphertext  using  the  public  half  of  the  key  pair  (i.e.,  the 
key  used  for  encryption)  (Anderson  2008,  171). 

The  challenge  for  the  attacker  and  an  encrypted  message  becomes  the  decryption 

of  an  intercepted  message.  The  attacker  needs  the  same  resources  needed  by  the 

legitimate  recipient:  the  key  and  the  cipher.  Users  always  keep  their  keys  secret,  and  they 

often  change  them  on  a  regular  basis  to  limit  the  damage  in  case  a  particular  key  gets 

compromised.  Keys  can  be  stored  in  the  memory  of  the  computer,  on  a  storage  device 
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such  as  a  floppy  disc  or  USB  drive,  or  on  an  external  processor  such  as  a  smart  card. 
Smart  cards  such  as  the  military  Common  Access  Card  have  the  advantage  that  they 
never  transmit  the  key  onto  the  eomputer  being  used  for  communication,  where  an 
attaeker  who  gained  access  to  the  memory  or  file  system  eould  steal  it.  Rather,  they 
reeeive  the  plaintext  from  the  eomputer,  perform  the  encryption  on  the  smart  card’s 
processor,  and  send  the  ciphertext  baek  to  the  computer  for  transmission.  Smart  cards 
lack  the  standard  file  system  of  a  general-purpose  computer,  making  it  mueh  more 
difficult  for  an  attacker  to  eopy  the  key  from  the  eard’s  memory  (Harris  2008,  191). 

While  keys  are  always  kept  seeret,  the  cipher  may  not.  The  security  community 
has  two  distinct  schools  of  thought  regarding  the  seerecy  of  ciphers  and  computer  code  in 
general.  One  side  supports  open-souree,  or  public  release,  because  scrutiny  by  the  world 
community  can  reveal  flaws  that  escaped  the  attention  of  the  designers.  Ciphers  are 
difficult  to  keep  secret,  and  their  compromise  may  allow  adversaries  to  discover  new 
flaws  and  execute  attacks.  The  other  side  supports  seerecy  of  ciphers  because  an  attaeker 
must  know  the  cipher  in  order  to  perform  a  eryptologic  attack.  Even  a  weak  and  flawed 
eipher  ean  provide  adequate  protection  if  the  adversaries  do  not  understand  how  it  works 
(Harris  2008,  668). 

The  deeision  on  whether  to  release  ciphers  or  make  them  seeret  depends  in  part 
upon  which  of  the  following  seenarios  seems  more  likely.  On  one  hand,  an  adversary 
might  examine  a  publie  cipher  and  find  a  flaw  that  system  designers  and  the  worldwide 
cryptographie  community  all  overlooked.  On  the  other  hand,  an  adversary  might  steal  a 
secret  cipher  and  discover  a  vulnerability  that  system  designers  failed  to  eatch.  This 
decision  depends  in  part  upon  the  development  methods  used  for  the  cipher.  Ciphers 
produced  by  a  contractor,  even  one  operating  in  a  classified  environment,  may  fall  victim 
to  the  widespread  threat  of  industrial  espionage.  Ciphers  produced  eompletely  within  the 
National  Security  Agency,  on  the  other  hand,  may  better  resist  the  industrial  espionage 
threat. 

Other  seeurity  risks  against  secret  ciphers  ean  also  influenee  the  public/seeret 

deeision.  Secret  ciphers  may  be  discoverable  by  reverse-engineering  attacks  upon 

hardware  that  has  fallen  into  enemy  eontrol.  Once  eompromised,  a  cipher  (unlike  the 
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encryption  key)  cannot  easily  be  changed;  it  may  take  several  years  to  develop  a  suitable 
replacement.  Finally,  an  adversary  that  discovers  the  cipher  may  share  it  with  any 
number  of  parties  hostile  to  the  United  States.  Secrecy  of  ciphers,  and  of  code  in  general, 
may  help  to  confound  an  attack,  but  the  overall  security  of  the  system  and  its  messages 
must  not  rely  primarily  upon  that  secrecy.  This  idea  was  first  proposed  in  1883  by 
Auguste  Kerckhoffs,  who  said  that  the  only  secrecy  should  be  in  the  key  and  that  the 
algorithm  should  be  publicly  known  (Harris,  2008,  668). 

Even  a  mathematically  perfect  cipher  may  fail  to  protect  the  confidentiality  of  a 
message  if  an  attacker  can  exploit  a  vulnerability  in  the  way  the  cipher  is  implemented  in 
hardware  or  software.  In  the  early  1960s,  the  National  Security  Agency  discovered  that 
attackers  could  read  encrypted  messages  by  measuring  the  electromagnetic  emanations 
coming  from  communications  hardware.  Code-named  “Tempest,”  this  program  also  led 
to  the  realization  that  emanations  depended  on  the  combination  of  components  and  how 
they  were  connected — a  far  more  complex  challenge  than  studying  individual 
components  in  isolation  (Boak  1973,  98).  Attackers  can  also  use  timing  analysis  or 
power  analysis  to  figure  out  the  cryptographic  key  and  other  protected  information  by 
carefully  measuring  the  time  or  electric  current  used  by  the  computer  performing  the 
encryption/decryption  (Anderson  2008,  533). 

A  perfectly  designed  and  implemented  cipher  may  protect  the  contents  of  network 
messages,  but  adversaries  may  still  deduce  some  important  information  by  conducting 
traffic  analysis.  Traffic  analysis  is  the  study  of  the  identity  of  the  sender  and  receivers  of 
messages  as  well  as  the  timing  and  number  of  messages  being  sent.  For  example,  a  spike 
in  traffic  from  a  particular  unit  may  imply  that  it  has  located  enemy  units  or  is  starting  an 
attack.  Friendly  forces  can  defeat  traffic  analysis  by  sending  decoy  traffic  to  disguise 
patterns  in  genuine  messages  (Harris  2008,  1087). 

Network-based  attacks  on  integrity  extend  the  techniques  used  when 
compromising  confidentiality.  Where  an  attack  on  confidentiality  copies  a  message  and 
decodes  it  to  learn  its  secrets,  attacks  on  integrity  seek  to  use  the  target’s  network  to 
inject  messages  with  false  information.  This  false  information  could  be  used  to  hide  the 
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attacker’s  forces,  create  diversions,  or  even  cause  fratricide  by  tricking  the  opposing  force 
to  fire  on  itself.  The  adversary  must  understand  the  target’s  communications 
infrastructure,  protocols,  ciphers,  and  encryption  keys  in  both  situations. 

Attackers  use  a  wide  variety  of  approaches  to  inject  false  information.  At  the 
simplest  level,  the  attacker  mimics  a  legitimate  network  node  and  sends  properly- 
formatted  but  false  data.  This  impersonation  attack  can  create  false  target  data,  orders,  or 
status  reports.  More  complex  attacks  use  session  hijacking  or  “man-in- the-middle” 
techniques  to  exploit  a  legitimate  communication  session  between  two  network  nodes. 
Session  hijacking  requires  the  attacker  to  observe  a  session  in  progress  and  then  conduct 
an  impersonation-type  attack  by  mimicking  one  of  the  participants,  assuming  its  identity 
in  the  conversation.  If  the  node  whose  identity  is  being  hijacked  can  be  silenced,  the 
attacker  can  continue  the  session  while  masquerading  as  that  node.  Man-in-the-middle 
attacks  work  only  when  the  two  network  nodes  under  attack  cannot  directly  communicate 
with  each  other,  as  is  the  case  over  a  wired  connection  where  the  wires  pass  through  a 
node  under  enemy  control.  In  this  case,  the  enemy  hijacks  the  session  in  both  directions, 
capturing  all  traffic  and  making  changes  as  desired  (Harris  2008,  1084-6). 

Authentication  tools  can  foil  attacks  on  integrity  by  forcing  network  nodes  to 
prove  their  identity  before  participating  in  a  communications  session.  These  tools 
typically  use  the  cryptographic  key  as  a  “shared  secret,”  where  possession  of  the  key 
proves  the  person’s  identity.  Both  symmetric  and  asymmetric  keys  can  serve  this 
function,  with  the  same  logistical  considerations  as  when  they  are  used  to  protect 
confidentiality.  In  the  case  of  asymmetric  encryption,  the  message  sender  uses  his  own 
private  key  to  encrypt  some  portion  of  the  message.  Properly  decrypting  that  portion 
with  the  sender’s  public  key  verifies  the  message  sender’s  identity  because  only  the 
sender  possesses  the  private  key  needed  for  encryption  (Harris  2008,  682). 

Message  integrity  tools  can  also  foil  attacks  on  integrity  by  making  it  impossible 

for  the  attacker  to  alter  the  message  content  without  those  changes  being  detected.  This 

task  generally  employs  a  cryptographic  hash  function,  which  uses  a  complex  algorithm  to 

distill  any  size  document  down  to  a  hash  value.  These  hash  values  are  typically  on  the 

order  of  128  bits  long,  and  they  are  sent  with  the  message  to  prove  that  the  message  has 
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not  been  altered.  Well-designed  hash  functions  cause  the  hash  value  to  change 
dramatically  at  the  slightest  change  of  the  original  file,  and  a  large  hash  value  makes  it 
infeasible  for  the  attacker  to  find  some  modification  that  would  produce  exactly  the  same 
hash  value  (Harris  2008,  714). 

To  check  message  integrity,  the  message  recipient  simply  runs  the  hash  function 
on  the  received  message  and  compares  this  generated  hash  value  with  the  hash  value  sent 
with  the  message.  A  match  proves  that  the  message  has  not  been  altered.  Of  course,  a 
wily  attacker  could  simply  change  the  message,  generate  a  new  hash  value,  and  send  the 
new  hash  value  along  with  the  altered  message;  however,  encrypting  the  hash  value 
prevents  that  from  happening  since  the  attacker  cannot  properly  encrypt  the  bogus  hash. 
In  addition  to  protecting  a  message  from  undetected  changes,  an  encrypted  hash  value 
links  the  message  to  its  sender  and  therefore  serves  as  a  digital  “signature”  used  for 
authentication  of  the  sender  (Harris  2008,  714-7). 

Hash  functions  go  beyond  simple  error  detection  and  correction  techniques  like 
cyclic  redundancy  checks,  checksums,  or  Hamming  codes.  These  techniques  protect 
messages  from  accidental  modification  during  transit  caused  by  electromagnetic 
interference  or  processing  errors,  but  an  attacker  could  easily  create  checksum  values  that 
match  his  altered  message.  Network  nodes  must  not  rely  on  error  detection  and 
correction  techniques  to  protect  messages  from  malicious  modification. 

A  public  key  infrastructure  (PKI)  formalizes  the  process  of  sharing  and  validating 
public  and  private  keys  so  that  message  recipients  can  trust  that  messages  report  their  true 
originators  and  contain  unaltered  content.  Under  a  PKI,  each  user  has  a  digital  certificate 
issued  by  a  trusted  Certificate  Authority  (CA).  These  certificates  contain  the  user’s 
identity,  his  public  key,  the  CA  signature,  and  other  protocol  information.  The  CA 
signature  consists  of  a  hash  of  the  certificate  data  encrypted  by  the  CA’s  private  key,  and 
it  proves  that  the  certificate  is  legitimate.  So  long  as  all  participants  trust  the  CA,  any 
certificate  signed  by  that  CA  can  be  trusted  and  used  to  validate  the  digital  signatures  of 
received  messages.  Larger  PKIs  may  have  multiple  layers  of  CAs  to  issue  large  numbers 
of  certificates,  but  each  subordinate  CA  in  this  situation  has  its  own  certificate  signed  by 

the  one  inherently  trusted  “root”  CA  (Harris  2008,  725-32). 
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Commercial  computer  networks,  including  home  users  accessing  merchant 
websites  on  the  Internet,  use  a  PKI  to  establish  encrypted  connections  and  verify  the 
identity  of  participants.  This  commercial  application  of  PKI  has  a  significant  weakness 
because  compromised  certificates  can  still  appear  to  be  valid.  The  original  intent  for 
PKIs  was  to  keep  certificate  revocation  lists  (CRTs)  that  list  any  digital  certificates  that 
should  no  longer  be  trusted.  As  the  Internet  grew,  however,  CRTs  grew  too  cumbersome 
to  update  and  check  (Harris  2008,  728-9).  Military  networks  have  an  advantage 
compared  to  the  Internet  because  the  closed  and  limited  nature  of  military  networks 
permits  an  effective  use  of  CRTs  and  a  more  reliable  defense  against  compromised 
certificates. 

The  final  type  of  attack  upon  integrity  involves  recording  a  legitimate 
communication  session  and  replaying  it  later.  Since  the  recorded  information  contains  all 
the  correct  cryptographic  keys,  formats,  and  hash  values,  it  would  appear  to  the  receiver 
to  be  a  legitimate  message  from  the  original  sender.  The  attacker  likely  would  not  even 
know  the  contents  of  the  message  he  captured,  but  injecting  “stale”  information  could 
cause  confusion  for  the  receiver.  Network  nodes,  therefore,  need  some  method  to  ensure 
that  replayed  messages  are  rejected. 

A  combination  of  time  stamps  and  nonces  guarantee  the  originality  of  friendly 
messages  and  defeat  the  replay  attack.  A  time  stamp  shows  the  age  of  the  original 
message,  and  receivers  can  automatically  reject  messages  older  than  a  chosen  age.  The 
nonce,  which  is  simply  a  randomly  selected  number,  proves  the  uniqueness  of  each 
legitimate  message.  When  all  network  nodes  agree  on  a  certain  age  threshold  beyond 
which  they  will  reject  incoming  messages,  then  they  simply  need  to  read  the  nonce  of 
each  message  they  receive  and  compare  it  to  a  list  of  received  nonces  within  the  age 
threshold.  Since  each  legitimate  message  will  have  a  unique  nonce,  any  message  that 
carries  the  same  nonce  is  rejected  as  a  replay  (Anderson  2008,  66-7;  Harris  2008,  756). 
This  assumes  that  the  attacker  cannot  decrypt  the  message,  replace  the  nonce  with  a  new 
value,  and  re-encrypt  it;  however,  any  attacker  with  the  ability  to  perform  those  steps 
could  launch  much  more  damaging  attacks  than  a  simple  replay. 


23 


B,  ATTACKS  ON  THE  COMPUTER 

Once  an  attacker  gains  access  to  a  computer  within  a  network,  a  vast  array  of 
attaeks  become  possible.  Where  a  network  attacker  operates  as  an  outsider  interfering 
with  message  flow  and  possibly  reading  secret  messages  and  injecting  false  information, 
a  computer  attaeker  assumes  the  mueh  more  dangerous  position  of  an  insider  eapable  of 
altering  both  data  and  programming  eode.  Any  attaek  technique  can  potentially  interfere 
with  availability,  confidentiality,  and  integrity  in  any  combination. 

Gaining  direct  access  to  one  of  the  computers  within  the  network  can  be  aehieved 
through  network  or  physical  access.  Network-based  aceess  starts  with  one  of  the 
integrity-based  network  attacks  discussed  above  and  involves  the  attaeker  injeeting  some 
sequence  of  commands  that  exploits  a  remote-aceess  feature  of  that  host  (Anderson  2008, 
636).  These  remote-access  features  may  give  network  administrators  the  ability  to 
control  or  configure  network  nodes  from  a  central  location  or  to  update  computer  code 
following  the  discovery  of  a  security  vulnerability  or  some  other  kind  of  bug.  Physical 
access  involves  aetual  possession  of  the  target  computer  and  manipulation  of  memory, 
eaehe,  or  proeessor  registers  to  install  malicious  code  or  false  data.  Further  information 
about  physical  access  will  be  presented  in  Chapter  IV. 

The  number  of  vulnerabilities  available  on  a  eomputerized  system  depends  largely 
upon  how  mueh  of  the  system  uses  general-purpose  hardware  and  software.  In  order  to 
save  money,  develop  systems  faster,  and  take  advantage  of  the  latest  technology  offered 
by  industry,  program  managers  frequently  use  commereial  hardware  and  software  as  the 
foundation  of  their  developing  systems.  Developers  take  these  general-purpose 
proeessors  and  software  and  program  them  to  perform  the  functions  needed  by  the  new 
system.  Unfortunately,  these  items  retain  the  inherent  ability  to  perform  any  function  if 
so  programmed,  so  attaekers  can  potentially  alter  a  device’s  programming  to  change  its 
behavior.  Adding  to  this  vulnerability  is  the  fact  that  many  commercial  applications  are 
not  designed  with  rigorous  security  as  a  top  requirement  and  therefore  can  contain 
vulnerabilities  that  ease  an  attacker’s  aecess  to  the  code.  Commenting  on  the  general 
lack  of  security  in  commercial  software  products,  Bruce  Schneier  wrote. 
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The  costs  of  adding  good  security  to  software  products  are  essentially  the 
same  ones  incurred  in  increasing  network  security — large  expenses, 
reduced  functionality,  delayed  product  releases,  annoyed  users — while  the 
costs  of  ignoring  security  are  minor:  occasional  bad  press,  and  maybe 
some  users  switching  to  competitors'  products.  The  financial  losses  to 
industry  worldwide  due  to  vulnerabilities  in  the  Microsoft  Windows 
operating  system  are  not  borne  by  Microsoft,  so  Microsoft  doesn't  have 
the  financial  incentive  to  fix  them.  If  the  CEO  of  a  major  software 
company  told  his  board  of  directors  that  he  would  be  cutting  the 
company's  earnings  per  share  by  a  third  because  he  was  going  to  really — 
no  more  pretending — take  security  seriously,  the  board  would  fire  him.  If 
I  were  on  the  board,  I  would  fire  him.  Any  smart  software  vendor  will  talk 
big  about  security,  but  do  as  little  as  possible,  because  that's  what  makes 
the  most  economic  sense.  (Schneier  2004) 

In  contrast,  systems  built  with  single-purpose  hardware  such  as  application- 
specific  integrated  circuits  lack  the  ability  to  deviate  from  their  programming  (Null  and 
Lobur  2006,  716).  To  use  this  option,  developers  must  capture  the  functionality  of  the 
system  and  build  those  functions  into  the  hardware  itself  While  appealing  from  a 
security  perspective,  this  option  presents  major  problems  with  development. 
Development  of  complex  computerized  systems  uses  an  iterative  approach,  where 
functions  are  built,  tested,  integrated,  and  tested  again  (Larman  2006).  Each  round  of 
testing  can  uncover  flaws  in  the  programming  that  must  be  fixed  for  the  next  version. 
Eurthermore,  users  often  change  their  requirements  during  and  after  development  as  they 
gain  proficiency  with  the  new  system  and  conceive  of  new  functions.  Making  all  those 
changes  in  software  alone  is  a  reasonable  task — one  with  which  most  developers  are 
familiar  since  the  commercial  and  educational  environments  use  those  skills  and 
techniques.  Trying  to  revise  the  design  of  an  integrated  circuit  and  produce  a  new  sample 
for  each  round  of  testing,  however,  would  be  prohibitively  expensive  and  time- 
consuming  and  is  not  a  practical  approach. 

Given  the  need  to  build  military  systems  upon  general-purpose  commercial 
hardware  and  software,  developers  must  devote  their  attention  to  those  remote-access 
features  that  can  be  exploited  by  an  adversary.  These  features  include  remote-update 
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capabilities  that  allow  software  updates  in  the  field,  remote-eonfiguration  tools  that  allow 
eontrol  and  eonfiguration  of  deployed  elements,  and  communieation  links  used  to 
exchange  sensor  data  and  eommand  and  eontrol  information. 

Remote-update  eapabilities,  where  system  administrators  push  software  updates 
to  network  hosts,  present  a  major  seeurity  ehallenge  to  the  integrity  of  executable  eode. 
These  features  rely  upon  authentieation  and  integrity  techniques  to  ensure  that  only 
appropriate  eonneetions  are  allowed  and  that  the  reeeived  data  has  not  been  altered.  An 
adversary  who  exploits  some  weakness  in  these  proteetive  measures  and  impersonates  a 
trusted  network  member  ean  gain  the  ability  to  reprogram  the  vietim  node  to  perform  any 
funetion  desired  by  that  adversary.  These  programming  attaeks  ean  shut  down  the  node, 
eorrupt  data,  or  open  a  eommunieations  ehannel  baek  to  the  adversary  to  relay  network 
information  (Harris  2006,  1044). 

Remote-eonfiguration  tools  present  less  of  a  threat  sinee  they  laek  the 
infrastrueture  to  direetly  alter  the  exeeutable  eode.  These  funetions  would  be  espeeially 
relevant  to  unmanned  vehieles  and  sensors  that  eannot  be  eommanded  by  a  physieally- 
present  operator.  An  adversary  impersonating  an  authorized  network  member  eould  shut 
down  or  otherwise  mis-configure  these  vehieles  and  sensors. 

Absent  any  direet  aeeess  to  the  exeeutable  eode  or  eonfiguration  functions,  as 
discussed  in  the  previous  ehapter,  attaekers  eould  still  exploit  weaknesses  in  the 
eommunieations  links  that  form  a  fundamental  part  of  any  network-eentrie  system. 
These  weaknesses  ean  include  unusual  or  boundary  eonditions,  buffer  overflows,  and 
injeetion  attaeks.  Eaeh  of  these  scenarios  involves  some  malieious  string  of  data  being 
passed  to  the  vietim  node  and  having  some  unexpeeted  and  detrimental  effeet. 

Attacks  involving  unusual  or  boundary  conditions  rely  on  the  faet  that  eomplex 
systems  have  so  many  possible  permutations  of  ineoming  data  that  developers  eannot  test 
them  all.  An  algorithm  written  with  the  assumption  that  ineoming  data  will  eonform  to 
eertain  ranges  and  formats,  may  produee  an  unstable  eondition  when  the  ineoming  data 
fails  to  obey  those  assumptions.  For  example,  the  F-22  fighter’s  avionies  system  failed 
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when  the  plane  erossed  the  international  dateline  because  of  a  programming  error  (CNN 
2007).  While  most  examples  of  this  type  of  problem  involve  functionality  failures,  an 
attacker  could  inject  data  strings  to  produce  similar  results. 

Additionally,  buffer  overflows  have  been  used  for  decades  and  still  present 
security  risks  to  computers.  Buffers  are  the  memory  storage  areas  reserved  by  the 
program  to  receive  incoming  data.  If  the  incoming  data  transmission  is  larger  than  the 
buffer  space,  that  data  could  possibly  overwrite  some  of  the  executable  code.  A  well- 
crafted  buffer  overflow  attack  can  cause  the  program  to  execute  part  of  that  transmitted 
data  as  program  code,  permitting  the  attacker  to  conduct  a  small-scale  reprogramming 
and  insert  malicious  code  such  as  viruses  or  worms  (McClure,  Scambray,  and  Kurtz 
2005,218-20). 

Even  when  systems  prevent  buffer  overflows,  injection  attacks  can  take  advantage 
of  systems  where  commands  are  transmitted  together  with  the  data.  These  systems  use 
specific  alphanumeric  strings,  special  characters,  or  some  other  mechanism  to 
differentiate  command  signals  from  data  (McClure,  Scambray,  and  Kurtz  2005,  561-2). 
An  attacker  with  network  access  and  knowledge  of  these  command  signals  could  perform 
the  same  kind  of  remote-configuration  attacks  discussed  earlier  even  if  the  system  lacks  a 
dedicated  control  mode. 

Defense  against  attacks  that  use  unexpected  inputs,  boundary  conditions,  buffer 
overflows,  or  command  injections  requires  developers  to  consider  all  possible 
combinations  of  input  data  in  code  analysis  and  testing.  Developers  should  also  use 
bounds-checking  functions  that  filter  out  ranges  of  data  that  could  never  be  received  in  an 
operational  environment.  The  field  of  software  safety  provides  useful  ideas  for 
protecting  security  by  suggesting  the  operation  of  a  separate,  parallel  function  that 
monitors  system  behavior  and  takes  action  when  the  system  does  something  unexpected 
or  unsafe.  Many  networks  already  use  intrusion  detection  or  prevention  systems  to 
perform  this  independent  monitoring  function.  Developers  must  also  scrutinize 
commercial  code  intended  for  use  in  the  system,  remove  any  unnecessary  functions  and 
interfaces,  and  insert  bounds-checking  functions  where  needed  (Joint  Software  System 
Safety  Committee,  E-10). 
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In  addition  to  the  scenarios  above  where  attackers  try  to  inject  bogus  data  or 
malicious  commands  into  the  system,  many  other  avenues  of  technological  attack  exist. 
The  specifics  of  these  techniques  are  beyond  the  scope  of  this  thesis  and  depend  upon  the 
hardware,  software,  and  protocol  configuration  in  use.  Some  of  the  risk  comes  from  the 
same  viruses,  worms,  and  other  malicious  code  that  regularly  threatens  commercial 
computer  networks.  If  the  network-centric  weapon  system  includes  commercial 
hardware  and  software,  it  must  include  the  same  defensive  measures  used  by  commercial 
networks  to  prevent  malicious  code  from  executing.  These  measures  include  strict 
configuration  management  that  requires  new  code  to  be  tested  prior  to  installation,  the 
use  of  access  controls  so  operational  users  cannot  install  software,  and  anti-virus  software 
running  on  developmental  machines  to  prevent  viruses  from  attaching  themselves  during 
system  development. 

Developers  must  decide  whether  their  executable  code  and  algorithms  should  be 
kept  secret  or  made  available  to  the  public.  This  decision  mirrors  the  same  issue  with 
cryptographic  algorithms  and  has  the  same  risks  and  benefits  to  both  options.  The  DoD 
has  begun  to  recognize  the  value  of  open-source  software,  where  the  source  code  is 
published  for  everyone  to  see  and  members  of  the  public  can  contribute  code  via  the 
project  team,  and  has  established  the  “Forge.mil”  Web  site.  This  website  builds  on  the 
open-source  model  of  the  SourceForge  website  that  provides  the  infrastructure  for 
community  collaboration  on  software  projects.  Using  the  “Forge.mil”  website, 
developers  of  military  systems  can  subject  their  code  to  public  scrutiny  and  benefit  from 
their  observations  and  contributions. 

Security  for  executable  code  (i.e.,  the  ability  of  software  to  resist  attacks) 
depends,  just  as  in  the  cryptography  scenario,  upon  the  secrecy  of  configuration  settings 
and  cryptographic  keys.  Developers  who  choose  to  keep  their  algorithms  secret  may 
achieve  some  additional  “security  through  obscurity,”  but  they  must  not  rely  upon  the 
algorithm  or  code  secrecy  to  provide  security.  Any  elements  that  provide  security  must 
be  easily  and  quickly  replaceable  in  the  event  these  elements  are  compromised,  and  the 
source  code  would  require  a  great  deal  of  time  and  effort  to  replace. 
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Much  of  the  security  effort  for  computerized  systems  focuses  on  managing 
complexity.  Developers  use  tools  like  security  policies  and  security  architectures  to 
understand  the  structure  of  the  system  and  control  the  ways  that  different  eomponents  can 
interact.  Since  attackers  ean  break  into  the  system  through  poorly  designed  or  mis- 
configured  interfaces,  these  tools  help  minimize  the  complexity  and  remove  unnecessary 
interconnects. 

The  seeurity  policy  defines  the  system’s  requirements  with  respect  to  security.  It 
identifies  and  prioritizes  assets  necessary  to  earry  out  the  military  missions,  establishes 
the  goals  regarding  protection  of  information,  and  defines  organizational  duties  and 
authorities.  The  seeurity  policy  emerges  from  an  examination  of  the  threats  against  the 
system  and  serves  to  defend  against  those  threats — but  only  where  the  risk  exceeds  the 
cost  of  the  defense.  Broad  poliey  statements  act  as  the  basis  for  security  standards  and 
guidelines,  which  create  rules  governing  the  legal  behavior  of  the  system.  The  standards 
and  guidelines  provide  the  basis  for  detailed  operating  and  administrative  proeedures  that 
direct  the  actions  of  operators  and  maintainers  (Harris  2008,  110-5). 

The  seeurity  arehitecture  provides  an  abstraet  representation  of  the  components 
and  intereonnections  of  a  system.  It  eaptures  the  functions  performed  by  each 
component  and  the  data  flow  throughout  the  network.  Developers  use  a  security 
architecture  to  illustrate  whieh  components  need  to  eommunicate  and  whieh  ones  must  be 
isolated.  Designing  the  components  around  the  architecture  helps  to  ensure  that  modules 
eommunicate  efficiently  without  violating  the  security  policy.  Defining  and  using  the 
seeurity  arehitecture  is  a  key  effort  in  systems  engineering  that  helps  developers  reduee 
system  complexity  and  better  understand  the  system’s  design  (Anderson  2008,  657-9). 

One  option  for  a  security  architecture  is  the  Trusted  Computing  Base  (TCB).  The 
TCB  represents  the  combination  of  all  security  protection  mechanisms  within  the  system, 
ineluding  hardware,  software,  and  firmware.  By  using  a  TCB,  developers  can  create  a 
small,  simple,  and  reliable  eonstruet  that  manages  system  processes  in  a  way  that 
enforees  the  seeurity  policy.  Capturing  the  proteetion  meehanisms  in  the  TCB  allows 
developers  of  the  rest  of  the  system  to  devote  their  effort  to  the  features,  reliability,  and 
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usability  aspects  of  operation  without  having  to  worry  as  much  about  security.  It  also 
allows  functionality  changes  to  be  installed  without  changing  the  security  posture  of  the 
system  (Harris  2008,  321-6). 

A  TCB  could  include  a  reference  monitor  that  mediates  access  between  users  and 
data  fdes.  It  could  also  provide  for  a  security  kernel  as  the  hardware,  software,  and 
firmware  within  the  TCB  that  implements  the  concept  of  the  reference  monitor.  The 
reference  monitor  concept  plays  a  major  role  in  protecting  the  confidentiality  of  systems 
that  process  information  of  different  classification.  Chapter  III  describes  the  reference 
monitor  in  greater  detail. 

C.  TESTING  AND  CERTIFICATION 

Testing  and  certification  for  security  differs  from  testing  and  certification  carried 
out  to  prove  the  functionality  of  software.  In  the  functionality  case,  tests  capture  the  most 
likely  scenarios,  configurations,  and  data  communications.  Failures  of  functionality  tests 
can  be  easily  detected  through  improper  system  behavior  or  incorrect  data  processing. 
Because  security  problems  often  emerge  from  unexpected  situations  and  since  testing 
alone  cannot  capture  every  possible  permutation  of  inputs  and  system  conditions,  security 
certification  must  also  rely  upon  an  examination  of  the  program  design.  This 
examination  looks  for  both  the  presence  of  security  protective  features  and  the  proper 
design  and  implementation  of  the  code.  Most  importantly,  it  verifies  that  the  security 
policy,  which  specifies  the  legal  behavior  for  the  system,  is  properly  implemented  and 
will  be  enforced. 

To  test  and  certify  the  computer  and  network  security  of  a  system  under 
development,  industry  and  the  DoD  often  rely  upon  an  international  program  called  the 
Common  Criteria  for  Information  Technology  Security  Evaluation  (CNSS  2003,  2).  This 
program,  sponsored  by  the  U.S.  National  Institute  of  Standards  and  Technology  and 
National  Security  Agency,  in  addition  to  similar  organizations  in  25  other  countries, 
provides  a  framework  for  evaluating  the  security  of  both  hardware  and  software.  The 
Common  Criteria  evaluation  studies  the  degree  of  assurance  that  the  product  under 
consideration  properly  implements  its  security  functions.  Each  evaluation  tests  a  product. 
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called  the  Target  of  Evaluation,  (TOE)  in  one  specifie  configuration  and  operational 
environment.  A  doeument  called  a  Seeurity  Target  defines  the  security  properties  of  the 
TOE  and  may  inelude  one  or  more  Proteetion  Profiles,  which  capture  the 
implementation-independent  seeurity  requirements  for  a  given  elass  of  deviee.  These 
seeurity  properties  in  the  Seeurity  Target  doeument  include  Seeurity  Eunctional 
Requirements,  whieh  speeify  funetions  that  the  TOE  must  perform,  and  Seeurity 
Assuranee  Requirements,  which  describe  the  measures  taken  during  development  to 
ensure  that  the  seeurity  funetions  will  operate  properly  (Signatories  of  the  Common 
Criteria  Recognition  Agreement  2009). 

The  evaluation  verifies  that  the  Seeurity  Eunetional  Requirements  are  satisfied 
and  rates  the  Seeurity  Assuranee  Requirements  by  providing  an  Evaluation  Assuranee 
Eevel  (EAL)  of  one  to  seven,  with  seven  being  the  highest  assuranee.  Higher  levels 
require  inereasingly  more  rigorous  and  formal  design  and  testing  and  an  aceordingly 
higher  cost  for  development.  The  formal  mathematieal  methods  used  to  prove  the 
security  of  systems  seeking  a  high  EAE  drive  developers  to  design  those  produets  in 
aeeordanee  with  the  evaluation  eriteria  (Signatories  of  the  Common  Criteria  Reeognition 
Agreement  2009). 

The  evaluation  also  verifies  that  the  seeurity  poliey  has  internal  eonsisteney,  the 
security  architecture  faithfully  matehes  the  poliey,  and  the  design  eorrectly  implements 
the  architeeture.  These  proeesses  take  a  great  deal  of  time  and  money,  delaying  product 
deployment  and  driving  eosts  beyond  the  ability  of  some  programs  to  handle.  The  time 
and  eost  of  an  evaluation  grows  with  both  the  EAE  desired  and  the  size  of  the  TOE,  so 
sehedule  and  budget  pressures  may  drive  program  managers  to  settle  for  a  lower  EAE 
than  they  might  otherwise  desire.  Evaluations  oriented  toward  a  lower  EAL  skip  the 
formal  mathematieal  verifieation  of  the  seeurity  model  and  present  a  risk  that  the  model 
may  eontain  vulnerabilities  (Signatories  of  the  Common  Criteria  Reeognition  Agreement 
2009). 

The  evaluation  proeess  also  eomplieates  the  eonfiguration  management  of  the 

deployed  system.  Sinee  the  evaluation  examines  the  TOE  in  one  speeifie  eonfiguration 

and  environment,  ehanges  to  the  eode  may  invalidate  the  evaluation  and  require  an 

31 


update.  A  program  using  incremental  and  evolutionary  development  methods  may  not  be 
able  to  afford  the  time  or  money  required  to  re-evaluate  each  version  of  the  system.  Use 
of  a  TCB  with  a  security  kernel  and  reference  monitor  may  avoid  these  problems  by 
grouping  functionality  changes  outside  the  part  of  the  system  that  requires  security 
evaluation.  The  conflict  between  the  desire  for  agile  development  and  the  need  for 
evaluated  security  requires  further  research  in  the  field  of  network-centric  system 
acquisition. 

Testing  the  hardware  and  software  for  security  flaws  provides  some  assurance 
about  system  security;  however,  it  cannot  guarantee  the  security  of  the  system  against  all 
technical  attacks.  Attackers  have  an  effectively  infinite  variety  of  methods  at  their 
disposal,  making  it  impossible  to  test  for  all  possible  attacks.  The  limited  value  of  testing 
underscores  the  value  of  a  secure  design,  making  essential  for  developers  to  include 
security  requirements  in  all  stages  of  design  rather  than  simply  trying  to  add  security 
features  to  an  already-built  product.  As  Bruce  Schneier  noted. 

The  real  lesson  is  that  the  patch  treadmill  doesn't  work,  and  it  hasn't  for 
years.  This  cycle  of  finding  security  holes  and  rushing  to  patch  them 
before  the  bad  guys  exploit  those  vulnerabilities  is  expensive,  inefficient, 
and  incomplete.  We  need  to  design  security  into  our  systems  right  from 
the  beginning.  We  need  assurance.  We  need  security  engineers  involved 
in  system  design.  This  process  won't  prevent  every  vulnerability,  but  it's 
much  more  secure  —  and  cheaper  —  than  the  patch  treadmill  we're  all  on 
now.  What  a  security  engineer  brings  to  the  problem  is  a  particular 
mindset.  He  thinks  about  systems  from  a  security  perspective.  It's  not  that 
he  discovers  all  possible  attacks  before  the  bad  guys  do;  ifs  more  that  he 
anticipates  potential  types  of  attacks,  and  defends  against  them  even  if  he 
doesn't  know  their  details.  I  see  this  all  the  time  in  good  cryptographic 
designs.  Ifs  over-engineering  based  on  intuition,  but  if  the  security 
engineer  has  good  intuition,  it  generally  works.  Kaminsky's  vulnerability 
is  a  perfect  example  of  this.  Years  ago,  cryptographer  Daniel  J.  Bernstein 
looked  at  DNS  security  and  decided  that  Source  Port  Randomization  was  a 
smart  design  choice.  That's  exactly  the  work-around  being  rolled  out  now 
following  Kaminsky's  discovery.  Bernstein  didn't  discover  Kaminsky's 
attack;  instead,  he  saw  a  general  class  of  attacks  and  realized  that  this 
enhancement  could  protect  against  them.  Consequently,  the  DNS  program 
he  wrote  in  2000,  djbdns,  doesn't  need  to  be  patched;  ifs  already  immune 
to  Kaminsky's  attack.  Thaf s  what  a  good  design  looks  like.  Ifs  not  just 
secure  against  known  attacks;  ifs  also  secure  against  unknown  attacks. 

We  need  more  of  this,  not  just  on  the  internet  but  in  voting  machines,  ID 
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cards,  transportation  payment  cards  ...  everywhere.  Stop  assuming  that 
systems  are  secure  unless  demonstrated  insecure;  start  assuming  that 
systems  are  insecure  unless  designed  securely.  (Schneier  2008a) 

Computer  products  used  for  the  DoD  also  require  certification  and  accreditation 
in  accordance  with  DoD  Directive  8500. OlE  and  Intelligence  Community  Directive  503. 
While  most  of  the  technical  work  in  this  process  examines  the  computer  and  network 
security  of  the  system,  the  certification  and  accreditation  process  is  designed  to  evaluate 
the  security  of  the  entire  system.  Details  on  this  process  will  be  provided  in  the  Chapter 
VII  discussion  on  whole-system  security. 
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III.  INFORMATION  SECURITY 


A  shift  to  network-centric  warfare  would  require  the  interconnection  of  combat 
units,  sensors,  logistics  elements,  intelligence  analysts,  and  commanders.  Each  of  these 
units  provides  its  own  type  of  data  to  the  network,  ranging  from  unclassified  data  on 
spare  parts  supplies,  to  secret  data  on  unit  positions  and  status,  to  top-secret  “sensitive 
compartmented  information”  (SCI)  data  from  surveillance  satellites  and  covert  sensors. 
However,  not  all  users  of  the  network  have  the  security  clearance  and  need-to-know 
required  to  gain  access  to  all  of  that  information.  This  discrepancy  between  the 
sensitivity  of  information  on  the  network  and  the  authorization  of  network  users  to  read, 
create,  and  modify  that  information  means  that  the  system  must  use  rigorous  controls  to 
limit  information  access  to  authorized  users.  Failure  to  enforce  these  controls  can  lead  to 
information  “spillage”  outside  of  its  approved  domain  and  compromise  of  sensitive 
information  to  hostile  forces. 

Office  automation  computer  systems  used  by  the  military  usually  perform  this 
access  limitation  function  through  the  use  of  Multiple  Independent  Levels  of  Security 
(MILS).  This  practice  requires  the  creation  of  a  separate  network  for  each  classification 
level.  Users  wishing  to  exchange  unclassified  logistics  or  business  information  use  an 
unclassified  computer.  Those  same  users  move  to  a  secret-level  computer  to  work  on 
secret  operational  information  and  then  move  to  a  top-secret-level  computer  to  process 
top-secret  intelligence  information.  The  MILS  architecture  assumes  that  any  user  of  a 
given  system  has  the  proper  security  clearance  and  formal  access  approval  for  all  of  the 
information  on  that  system.  This  security  mode  of  operation  is  called  “dedicated  mode” 
when  all  users  also  have  a  need-to-know  for  all  information  and  “system  high  mode” 
otherwise.  Systems  containing  SCI  or  special-access  program  information  may  operate 
in  “compartmented  security  mode”  when  users  have  different  formal  access  approvals 
and  need-to-know  (Harris  2008,  354). 

The  MILS  architecture  works  well  for  office  workers  who  have  room  for  multiple 
computers  on  their  desks  or  in  their  workspaces.  It  also  works  well  where  each  type  of 
information  exists  entirely  on  only  one  of  the  networks  and  does  not  span  multiple 
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systems.  MILS  presents  major  logistieal  problems,  however,  when  users  laek  the  ability 
to  use  multiple  eomputers  at  one  time  or  when  information  flows  aeross  different  security 
domains.  Operators  of  airplanes,  tanks,  and  infantry  units  lack  the  space  for  multiple 
computer  systems,  and  their  operations  naturally  combine  data  of  many  classifications 
and  compartments  onto  a  single  operational  picture. 

Network-centric  weapon  systems  could  solve  the  logistical  and  operational 
problems  of  the  MILS  architecture  by  using  a  Multi-Level  Security  (MLS)  architecture. 
MLS  allows  data  of  different  security  classifications  to  be  combined  onto  a  single 
computer  system  and  network.  To  protect  data  confidentiality,  MLS  systems  assign 
classification  labels  to  each  subject  (users  and  user  processes)  and  object  (files  and  data 
elements),  and  ensures  that  subjects  only  access  objects  for  which  they  possess  an 
appropriate  label.  For  example,  a  user  with  a  secret  clearance  would  be  granted  access  to 
secret,  confidential,  and  unclassified  information  but  not  to  top-secret  information 
(Anderson  2008,  239-73). 

To  enforce  this  label-based  access  control,  MLS  systems  use  a  reference  monitor 
and  the  Bell-LaPadula  model.  A  reference  monitor  is  a  small  process  operating  in  the 
security  kernel  of  the  operating  system  through  which  all  information  flow  between  users 
and  data  files  must  pass.  When  implemented  properly,  the  reference  monitor  cannot  be 
modified  or  bypassed  and  is  simple  enough  to  be  rigorously  evaluated  and  proven  secure. 
As  a  central  part  of  the  security  architecture,  it  enforces  the  security  policy  and  allows 
components  to  communicate  with  each  other  only  when  the  messages  conform  to  that 
policy  (Harris  2008,  327-8). 

In  the  case  of  the  Bell-LaPadula  model  of  access  control,  the  reference  monitor 
prohibits  reading  information  above  the  object’s  clearance  and  also  prevents  writing 
information  below  the  object’s  clearance.  Both  rules  protect  confidentiality,  the  first  by 
prohibiting  users  from  accessing  information  beyond  their  clearance  and  the  second  by 
preventing  users  from  “spilling”  information  of  one  level  onto  a  file  with  a  lower 
classification  level.  Depending  on  the  application,  developers  may  use  other  models 
where  integrity  takes  priority  over  confidentiality.  For  example,  the  Biba  model  defines 
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levels  of  integrity  such  that  information  with  a  high  integrity  label  can  be  trusted  more 
than  information  with  a  lower  label.  The  mechanisms  of  the  Biba  model  work  in  the 
opposite  manner  as  the  Bell-LaPadula,  so  users  cannot  write  up  to  higher  integrity  levels 
or  read  down  to  lower  integrity  levels  (Harris  2008,  327-38). 

To  access  a  MLS  computer  system,  users  log  on  and  select  a  security  level.  For 
example,  a  user  cleared  for  Secret  information  can  select  a  Secret,  Confidential,  or 
Unclassified  level.  Selection  of  the  correct  security  level  depends  upon  the  task  at  hand 
and  can  be  changed  if  the  user  wants  to  start  working  on  a  different  task.  It  is  essential  to 
select  the  appropriate  level  because  choosing  a  level  too  low  for  the  task  will  prevent  the 
user  from  being  able  to  read  the  desired  files;  for  example,  a  user  logged  on  at  an 
Unclassified  level  will  be  unable  to  access  files  labeled  Secret.  Choosing  a  level  too  high 
for  the  task  is  also  a  problem  because  the  classification  label  of  any  modified  files  will  be 
changed  to  match  the  active  security  level.  For  example,  if  a  user  logged  on  at  a  Secret 
level  makes  a  change  to  an  Unclassified  file,  that  file’s  security  label  will  change  to 
Secret  and  it  will  no  longer  be  accessible  at  the  Unclassified  level. 

This  need  to  operate  at  the  correct  security  level  for  the  task  at  hand  can  force 
users  to  change  their  security  level  frequently  during  the  course  of  their  work,  depending 
upon  how  often  these  users  need  to  access  files  of  different  classifications.  Desk-bound 
knowledge  workers  such  as  intelligence  analysts  or  mission  planners  may  find  this 
security  level  switching  an  inconvenience,  but  a  warfighter  operating  a  network-centric 
weapon  system  would  find  it  impossible  to  change  logon  contexts  without  causing  a 
major  operational  disruption. 

Furthermore,  MLS  systems  assume  that  each  system  will  be  accessed  by  only  one 
person  and  that  the  user’s  personal  identification  and  authentication  credentials 
correspond  to  that  one  person.  Again,  this  model  works  well  for  the  knowledge  workers 
who  have  their  own  computer  terminals  within  their  own  individual  workspaces,  but 
warfighters  typically  do  not  enjoy  these  conditions.  Operators  of  network-centric  weapon 
systems  such  as  ship  or  tank  crews  often  operate  their  terminals  as  a  team.  Even  if  a 
terminal  is  primarily  operated  by  one  watchstander,  its  contents  may  be  displayed  to 
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several  other  people  who  are  not  identified  and  authenticated  by  the  system.  Physical 
security  controls  can  compensate  for  this  problem  by  ensuring  that  everyone  physically 
capable  of  observing  or  operating  the  terminal  has  a  clearance  and  access  equal  to  the 
primary  operator  who  is  logged  in,  but  this  workaround  defeats  the  underlying 
assumption  that  all  users  are  identified  and  authenticated  before  being  granted  access. 

A  more  appropriate  architecture  for  connecting  network  nodes  with  different 
security  levels  can  be  built  by  using  Cross-Domain  Solutions  (CDS).  A  CDS  describes 
the  use  of  high-assurance  guards  and  filters  to  allow  the  interconnection  of  network 
segments  and  elements  that  operate  at  different  security  levels  without  allowing 
information  transfer  into  unauthorized  areas.  These  guards  and  filters  examine  the  data 
trying  to  flow  from  a  higher-security  domain  to  a  lower-security  one  and  prevent  any 
high-security  data  elements  from  passing  through.  Configuration  of  a  CDS  can  be 
complex  depending  upon  the  type  of  information  exchanged,  and  any  mis-configuration 
or  failure  to  anticipate  data  types  or  formats  could  lead  to  the  compromise  of  sensitive 
information. 

A  CDS  architecture  provides  a  way  for  sensors,  command  centers,  and  weapon 
systems  to  share  information  without  allowing  complete  visibility  into  all  the  information 
contained  within  each  node.  For  example,  a  remote  sensor  that  provides  data  at  the  Top 
Secret  SCI  level  can  feed  its  data  to  a  command  center  approved  to  handle  that  level  of 
information.  The  command  center  can  then  strip  away  data  elements  that  identify  the 
information’s  source  and  method  of  collection,  thus  reducing  its  classification  level  to 
Secret,  and  send  the  contact  report  to  a  contact  database  for  sharing  with  warfighters. 
The  guard  connecting  the  command  center  and  the  contact  database  uses  a  customized 
algorithm  to  examine  the  command  center’s  transmission  for  any  information  above  the 
Secret  level  and  blocks  any  such  data. 

Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  62II.02C  governs  the  process 
for  developing  and  getting  approval  to  operate  a  CDS.  This  process  ties  into  the  overall 
certification  and  accreditation  process  that  will  be  described  in  Chapter  VII.  A  CDS  does 
not  provide  the  same  rigorous  security  as  a  MLS  system,  but  it  can  allow  greater 
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operational  flexibility  with  an  aeeeptable  level  of  risk,  espeeially  for  systems  that 
eommunicate  with  fixed  message  formats.  The  use  of  fixed  message  formats  makes  it 
difficult  for  buggy  or  malicious  processes  to  send  sensitive  information  into  lower- 
security  domains. 

Even  a  well-designed  CDS  or  MLS  system  can  still  fall  victim  to  an  attack  on 
confidentiality  through  the  use  of  covert  channels  and  traffic  analysis.  A  covert  channel 
is  any  unusual  or  unexpected  method  of  bypassing  the  security  mechanism  and  sending 
highly  sensitive  information  to  a  lower-security  domain.  For  example,  if  some  network 
resource  is  visible  to  both  the  high  and  low  sides  of  a  network,  the  high  side  could  send 
information  to  the  low  side  by  changing  some  characteristic  of  the  shared  resource.  This 
example  would  require  both  sides  of  the  network  to  have  some  covert  program  installed 
that  can  translate  the  changes  in  the  network  resource  into  a  digital  data  stream.  Since 
covert  channels  can  use  a  vast  array  of  methods,  implementing  a  system  that  provably 
does  not  leak  information  is  extremely  challenging  (Anderson  2008,  263-5). 

The  concept  of  distributed  information  sharing  resembles  the  current  discussion  in 
industry  about  “Cloud  Computing”  and  Service  Oriented  Architectures.  Cloud 
Computing  refers  to  the  infrastructure  that  allows  information  and  services  to  be  hosted 
in  a  central  location  and  provided  to  users  upon  demand.  A  related  concept.  Service 
Oriented  Architecture  refers  to  the  standardization  and  centralization  of  computing 
services  so  they  can  be  used  by  multiple  units  of  a  larger  organization  (Hurwitz  et  al. 
2007).  Information  stored  within  the  network,  rather  than  locked  up  inside  one  isolated 
unit,  can  improve  the  situational  awareness  of  the  friendly  forces  but  also  be  at  greater 
risk  of  compromise.  Developers  must  decide  carefully  the  maximum  sensitivity  of 
information  allowed  to  be  stored  within  the  larger  network.  This  decision  requires  a  risk 
analysis  of  the  methods  of  compromise  and  the  tactical  advantages  of  having  the 
information  in  a  distributed  form  (Zittrain  2009). 

In  addition  to  information,  security  classifications  can  also  be  applied  to 
hardware.  Assigning  a  classification  level  places  requirements  for  storage  and  handling 
that  seek  to  prevent  theft  or  sabotage.  In  practice,  however,  it  is  difficult  to  classify 
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hardware  because  the  security  controls  may  place  a  significant  burden  on  operators  and 
maintainers.  Developers  must  seek  a  balance  between  the  need  for  efficient  handling  and 
the  need  to  prevent  theft  and  loss  (Boak  1973,  22). 
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IV.  PHYSICAL  SECURITY 


Physical  security  for  a  network-centric  weapon  system  goes  beyond  the  “gates, 
guards,  and  guns”  that  form  the  eore  of  physieal  seeurity  in  a  generie  military  eontext. 
Sinee  the  eomponents  of  this  system — the  tanks,  planes,  ships,  and  troops — will  be 
involved  in  eombat  and  eombat-support  operations,  they  have  different  physieal  seeurity 
needs  than  buildings  and  bases.  Enemy  forees  ean  still  threaten  the  system,  however,  in 
three  ways  that  involve  physieal  eontaet  with  the  hardware.  First,  they  ean  salvage 
funetioning  network  hardware  from  eaptured  friendly  units  and  use  that  hardware  to 
monitor  eommunieations  and  transmit  false  information.  Seeond,  they  ean  eorrupt  the 
manufacturing  process  of  the  system  hardware  and  implant  their  own  hardware  deviees 
that  perform  some  malieious  funetion.  Third,  they  ean  simply  destroy  the  network  nodes 
and  remove  the  ability  of  system  units  to  communieate  with  eaeh  other. 

A,  EAVESDROPPING  AND  SPOOFING  USING  CAPTURED  HARDWARE 

Most  eomputer  seeurity  seenarios  involve  an  attacker  intercepting  network 
eommunieations  or,  in  the  worst  case,  remotely  aceessing  a  network  host  and  planting  a 
malieious  program.  With  network-centrie  weapon  systems,  however,  comes  the 
additional  problem  of  physieal  attaeks  on  the  eomputer  hardware  itself.  Sinee  the 
networking  hardware  will  be  installed  on  ships,  tanks,  planes,  and  even  infantry  units,  it 
must  be  assumed  that  the  enemy  will  at  some  point  gain  physieal  possession  of  that 
hardware.  Onee  this  happens,  the  hardware  ean  be  used  to  eavesdrop  on  friendly 
eommunieations  or  insert  false  information.  If  the  system  is  still  funetioning,  the  enemy 
may  have  aeeess  to  the  entire  situational  awareness  picture,  knowing  everything  the 
friendly  forces  know  and,  most  importantly,  whieh  enemy  forees  are  still  undeteeted 
(Commission  on  Physical  Sciences,  Mathematies,  and  Applieations  2000,  180). 

Operators  may  have  the  opportunity  to  perform  an  emergeney  destruction  when 
eapture  beeomes  likely.  Sueh  procedures  usually  focus  on  cryptologic  keys  hardware  but 
ean  extend  to  all  sensitive  equipment.  These  proeedures,  however,  assume  that  operators 
will  have  the  time  and  ability  to  eonduet  a  thorough  destruction  and  that  the  enemy  will 
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be  unable  to  reeonstruet  the  destroyed  equipment.  Designing  for  emergeney  destruetion 
ean  be  a  ehallenge  sinee  operators  need  robust  equipment  that  survives  the  rigors  of 
eombat.  This  very  quality  of  robust  design  makes  hardware  diffieult  to  destroy 
intentionally  and  more  likely  to  fall  into  enemy  hands  (Boak  1973,  47). 

An  attaeker  who  gains  possession  of  a  funetioning  network  hardware  unit  can  try 
to  access  any  information  stored  within  that  unit’s  memory.  This  information  can  include 
a  recent  situational  awareness  picture — a  summary  of  the  positions  and  status  of  all 
friendly  units  and  the  estimated  position  and  status  of  any  detected  enemy  units.  The 
attacker  might  also  try  to  recover  any  cryptographic  keys  stored  in  the  unit  and  used  for 
authentication  and  message  encryption.  All  this  information  would  be  stored  in  volatile 
memory  (e.g.,  memory  chips)  and  non-volatile  memory  (e.g.,  flash  memory  or  disk 
drives),  and  since  this  hardware  will  likely  be  built  to  commercial  standards  it  may  not  be 
too  difficult  to  copy  and  read  this  information.  Law  enforcement  units  commonly  do  this 
as  a  forensic  analysis  of  computers  seized  from  criminal  suspects  (Harris  2008,  876-9). 

System  developers  can  use  tamper  resistance  to  make  it  difficult  for  attackers  to 
extract  information  from  captured  hardware.  For  example,  the  IBM  4758  processor 

responds  to  tamper  attempts  in  hardware  by  quickly  zeroizing  its  secrets 
and  executing  a  coprocessor  state  change,  without  requiring  software 
intervention.  Temper  conditions  include  penetration  attempts,  temperature 
extremes,  voltage  variation,  and  radiation.  (Dyer  et  al.  2001  60) 

However,  perfect  tamper  resistance  is  impossible  to  achieve,  and  designers  cannot 
objectively  determine  how  tamper-proof  their  hardware  is  (Schneier  2000,  215).  The 
tamper-resistance  challenge  is  complicated  by  attacks  that  use  non-invasive  methods  that 
would  not  trigger  a  reaction  from  the  target  hardware.  For  example,  Paul  Kocher’s 
differential  power  analysis  technique,  created  in  1998  to  extract  the  private  key  from 
smart  cards,  measures  the  power  used  during  several  hundred  known  transactions  with 
the  card  to  deduce  the  key  value  (Anderson  2008,  533). 

Tamper-resistant  designs  must  compete  against  an  ever-improving  array  of 
forensic  tools  and  techniques  that  can  extract  data  from  seemingly  secure  products. 
Recent  demonstrations  have  shown  that  data  in  volatile  memory  chips  can  be  extracted 
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by  cooling  them  down  before  removing  them  from  the  target  eomputer  (Jaekson  2008). 
Hard  drives  or  flash  memory  chips  can  be  copied  and  subjected  to  brute-force  attacks  on 
any  encrypted  contents.  Attackers  can  re-construct  deleted  data  from  any  magnetic 
medium  by  looking  for  the  minute  traces  of  residual  magnetism  left  behind  after  files  are 
deleted  or  overwritten  (Anderson  2008,  490).  Overall,  it  is  exceptionally  difficult  to 
protect  information  when  the  medium  that  holds  it  is  in  enemy  hands. 

The  use  of  asymmetric  encryption  can  reduce  the  risk  that  the  enemy  will  recover 
a  cryptographic  key  from  a  captured  hardware  deviee  and  use  that  key  to  intercept 
friendly  communications.  By  recovering  a  unit’s  seeret  key,  the  attacker  can  only 
decrypt  messages  sent  to  that  partieular  device.  Likewise,  with  the  effort  to  use  the 
eaptured  unit  to  injeet  false  information  into  the  friendly  network,  recovering  a  secret  key 
would  allow  the  attaeker  to  impersonate  only  that  specific  device.  If  the  friendly  network 
uses  a  robust  PKI  and  the  loss  of  the  friendly  unit  is  noted,  network  administrators  can 
place  that  unit’s  PKI  certificate  onto  a  certificate  revoeation  list  and  prevent  friendly  units 
from  trusting  any  further  messages  from  that  unit. 

In  addition  to  using  eaptured  hardware  to  steal  seerets  and  send  bogus 
information,  attaekers  can  also  conduct  reverse-engineering  activities  to  learn  the  details 
of  the  hardware  designs.  Once  the  designs  are  well  understood,  an  industrially 
sophisticated  enemy  can  then  manufacture  their  own  versions  of  the  units  and  use  these  in 
the  field  to  disrupt  the  friendly  network  or  to  impersonate  friendly  units  and  inject  false 
information.  Careful  use  of  cryptographie  authentication,  such  as  that  provided  by  a  PKI, 
would  limit  the  effeetiveness  of  these  attacks,  and  make  imposter  units  capable  of  little 
more  than  low-level  jamming  and  noisemaking. 

The  reverse-engineering  threat  also  extends  to  the  software  and  firmware  resident 
on  any  captured  hardware.  Even  though  any  code  would  exist  only  in  the  form  of  binary 
executables  (instead  of  source  code),  adversaries  could  use  reverse  code  engineering  tools 
like  disassemblers  and  debuggers  to  reeonstruct  the  source  code  and  learn  the  details  of 
the  algorithms  in  use.  They  eould  use  this  knowledge  to  discover  weaknesses  in  the 
proeessing  algorithms  and  develop  new  code-based  attacks  (Petkari  and  Chuvakin  2004, 

9). 
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B,  MALICIOUS  HARDWARE 

The  hardware  supporting  network-centrie  operations  may  fall  into  enemy  hands 
during  its  construction  as  well.  The  use  of  commercial  hardware  designs  and  fabrication 
means  that  the  physical  production  of  processor  chips  will  take  place  outside  of  direct 
military  observation  and  control.  This  is  especially  true  for  hardware  produced  overseas, 
where  factory  managers  may  face  pressure  from  intelligence  services  that  may  be  hostile 
to  the  United  States  (King  et  al.  2008). 

Just  as  malicious  code  can  be  introduced  into  software  or  firmware,  it  can  also  be 
embedded  into  the  design  of  microprocessor  hardware.  A  hostile  production  facility  can 
create  back-door  access  points,  logic  bombs  designed  to  cause  failures  when  certain 
conditions  are  met,  or  covert  transmission  functions  that  send  data  to  hostile  collection 
points  or  introduce  flaws  in  the  cryptographic  functions.  Detecting  these  functions  can 
prove  extremely  difficult  as  they  consist  of  minor  variations  in  the  arrangement  of  the 
millions  of  transistors  and  connections  found  on  modem  processors  (King  et  al.  2008). 

To  mitigate  the  risk  of  malicious  hardware,  program  managers  must  provide 
oversight  and  security  for  their  entire  supply  chain.  They  should  inspect  the  final  design 
of  custom-made  hardware  and  ensure  that  the  fabrication  process  faithfully  reproduces 
that  design.  Many  hardware  designs  will  use  existing  commercial  processors,  meaning 
that  the  chips  were  designed  before  they  were  selected  for  military  use  and  therefore  it  is 
unlikely  that  an  adversary  would  have  implanted  a  military-specific  malicious  process. 
In  this  case,  the  program  manager  must  ensure  that  the  production  process  does  not  get 
altered  and  that  the  units  supplied  to  the  military  project  are  identical  to  those  provided  to 
the  commercial  market.  Finally,  programs  may  decide  to  avoid  certain  vendors  when  the 
risk  is  too  high,  such  as  when  the  DoD  canceled  its  decision  to  buy  SIPRNet  computers 
from  the  Chinese-owned  company  Lenovo  in  2006  (U.S.  Congress  2008,  73). 

The  risks  from  malicious  hardware  may  not  exceed  the  risks  created  from  the  lack 
of  security  effort  put  into  commercial  software,  but  both  parts  of  the  supply  chain  require 
careful  attention.  Dr.  James  Mulvenon,  testifying  before  Congress  in  2008,  said. 
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I  would  obviously  agree  that  the  supply  chain  is  a  big  problem, 
particularly  given  the  increasing  percentage  of  these  products  that  are 
being  manufactured  in  China,  the  pressure  that’s  being  put  on  some  of 
these  companies  to  include  Chinese  standards,  which  involves  giving  up 
source  code  for  Chinese-designated  companies  to  then  be  able  to  build  the 
APIs  to  make  them  compatible  with  those  Chinese  standards.  But  we 
should  also  look  closer  to  home  as  well  as  in  the  sense  that,  as  a  Mac  user 
since  ’87,  I  can  tell  you  that  Microsoft  and  its  buggy  code  probably 
represents  a  far  graver  information  warfare  threat  to  the  United  States  than 
a  lot  of  backdoor  Chinese  equipment.  But  as  long  as  we  have  a  low  bid 
acquisition  strategy  in  that  area,  we’re  going  to  go  down  that  road,  and  it 
requires  much  more  attention  to  code  auditing  and  hardware  auditing  than 
we  do  right  now.  (U.S.  Congress  2008,  74) 

C.  HARDWARE  DESTRUCTION 

Much  of  the  discussion  about  computer  network  security  centers  around  the 
complex  and  obscure  ways  their  programming  can  be  altered  or  configurations  changed. 
In  a  military  situation,  however,  the  quickest  way  to  attack  the  availability  of  a  network  is 
to  simply  destroy  some  of  the  hardware.  As  Bruce  Schneier  pointed  out,  “One  of  the 
characteristics  of  denial-of-service  attacks  is  that  low-tech  is  often  better  than  high  tech; 
Blowing  up  a  computer  center  works  much  better  than  exploiting  a  Windows  2000 
vulnerability”  (Schneier  2000,  39).  A  dispersed  network  that  includes  warfighters, 
commanders,  and  sensors  would  require  a  great  deal  of  hardware  to  propagate  the  signals 
throughout  the  network,  and  this  hardware  would  include  relay  stations  on  satellites, 
planes,  ships,  and  ground  vehicles  and  facilities.  These  relay  stations  would  serve  to 
collect  messages  from  nearby  units  and  re-transmit  them  to  other  units  and  relay  stations, 
eventually  delivering  the  message  to  the  entire  network.  Destroying  some  of  these 
stations  could  effectively  remove  some  of  the  nodes  off  the  network  and  therefore  make 
them  unable  to  contribute  to  the  tactical  operations. 

Destroying  these  network  relay  stations  could  prove  especially  easy,  especially 
when  compared  to  the  effort  needed  to  destroy  actual  warfighting  units.  In  order  to  reach 
a  large  number  of  network  nodes,  the  relay  stations  would  have  to  be  positioned  in  an 
easily  observed  location.  They  would  also  need  to  transmit  more  frequently  and  with 
higher  power  then  the  warfighting  units  or  sensors,  further  raising  their  visibility. 

Unfortunately,  a  location  visible  to  friendly  forces  would  likely  also  be  visible  to  enemy 
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ones.  The  enemy  may  make  his  first  strike  foeus  on  networking  hardware,  eausing  a 
long-term  denial-of-serviee  on  the  friendly  network.  Robbed  of  their  ability  to 
eommunieate,  friendly  forees  would  have  to  revert  to  less-effeetive  legaey  radio  links  or 
just  give  up  on  eommunieations  and  perform  independent  operations.  These  independent 
operations  are  exaetly  the  opposite  of  the  integrated,  network-eentrie  operation  for  whieh 
the  units  were  trained,  so  friendly  forees  would  suffer  a  dramatie  loss  of  effeetiveness. 

The  problem  of  vulnerability  to  physieal  attaek  is  espeeially  aeute  for  satellites. 
The  U.S.  military  has  designed  mueh  of  its  eommunieations  infrastrueture  to  rely  on 
satellites,  and  a  future  network-eentrie  arehiteeture  would  likely  follow  this  philosophy. 
Historieally,  orbital  spaee  has  been  a  bastion  for  the  U.S.,  but  reeent  advanees  in  anti¬ 
satellite  weapons  have  shown  that  hostile  nations  ean  knoek  them  out.  China,  in 
partieular,  has  demonstrated  the  ability  to  destroy  or  disable  satellites,  and  reeent  writings 
of  the  Chinese  army  suggest  that  satellites  would  be  the  first  targets  in  a  eonflict  with  the 
U.S.  (U.S.  Congress  2008,  10). 

Given  the  diffieulty  of  hardening  or  hiding  network  relay  stations  on  the 
battlefield,  the  only  remaining  method  of  assuring  availability  may  be  the  deployment  of 
a  large  number  of  smaller  and  highly  mobile  stations.  Unmanned  Arial  Vehieles  (UAVs) 
eould  serve  this  funetion  well  if  they  deployed  in  large  numbers  and  formed  a  mobile  ad- 
hoe  network  to  pass  information.  Given  a  robust  networking  protoeol  that  ean  quiekly 
adapt  to  the  loss  of  network  members  but  not  overwhelm  the  system  with  repetitive  or 
eireular  traffie,  friendly  forees  ean  replenish  the  UAVs  as  they  are  disabled  and  maintain 
network  eonneetivity.  A  large  number  of  small  satellites  eould  also  perform  this 
funetion,  replaeing  the  small  number  of  large  and  vulnerable  satellites  eurrently  in  use. 
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V.  OPERATIONAL  SECURITY 


The  operational  philosophy  behind  network-eentrie  warfare  assumes  that 
warfighters,  sensors,  and  eommanders  will  have  continuous  data  links  available  to  share 
their  contact  information,  status,  and  orders.  Unfortunately,  radio  transmissions  can  be 
easily  detected  by  enemy  forces,  revealing  the  position  and  movement  of  friendly  units 
and  even  providing  some  clues  to  the  status  of  those  units.  Since  military  tactics  often 
rely  on  stealth  and  surprise,  the  emanations  needed  to  participate  in  the  network  can  leave 
friendly  forces  at  a  severe  disadvantage.  Developers  of  network-centric  systems, 
therefore,  must  consider  the  operational  security  needs  of  friendly  forces  to  operate 
without  detection  from  the  enemy. 

The  need  to  operate  without  detection  greatly  affects  covert  units  such  as 
submarines,  stealth  aircraft,  and  Special  Forces  units.  These  units,  termed  disadvantaged 
users,  typically  operate  without  making  any  detectable  emanations,  allowing  them  to 
receive  information  from  the  network  but  not  to  transmit  anything  (Goshorn  2008,  3). 
They  rely  upon  their  covert  status  for  mission  effectiveness  and  even  their  survival  since 
they  lack  the  ability  to  withstand  or  repel  a  significant  attack. 

The  inability  to  transmit  to  the  network  presents  both  tactical  and  technical 
problems.  Tactically,  the  network-centric  military  of  the  future  will  adopt  a  doctrine  that 
assumes  connectivity  among  all  warfighters,  sensors,  and  commanders.  Units  will  train 
to  use  the  common  situational  awareness  picture  created  by  all  network  nodes,  and  their 
tactics  will  be  based  on  this  information  sharing.  The  presence  of  friendly  units  operating 
off  the  network  could  complicate  this  tactical  assumption  and  increase  the  risk  of  friendly 
fire. 

The  technical  problem  comes  from  the  possible  use  of  a  connection-oriented 
protocol  for  network  communication.  Connection-oriented  protocols  establish  a 
communications  session  between  the  sender  and  receiver  as  the  first  step  of  any 
information  exchange,  and  they  can  authenticate  each  other  and  create  a  cryptographic 
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key  just  for  that  session.  Most  importantly,  they  require  both  parties  to  aeknowledge  any 
data  paekets  sent  by  the  other  party.  This  acknowledgement  ensures  that  all  the  data 
arrives  intact  (Comer  1999,  331). 

Any  network  member  restricted  from  transmitting  but  still  wishing  to  receive 
network  information  would  be  unable  to  use  a  connection-oriented  protocol  since  they 
could  not  establish  a  session  or  acknowledge  packets.  They  would  typically  have  to  use  a 
connectionless  protocol  to  carry  one-way  data  transfers.  Connectionless  protocols  are 
commonly  used  on  the  Internet  to  carry  streaming  audio  and  video  feeds,  and  they 
provide  no  protection  against  data  loss.  Corrupted  packets  may  be  recognized  as  such  by 
the  receiver  and  disregarded,  but  since  the  receiver  has  no  way  to  ask  for  the  packet  to  be 
re-sent,  that  data  is  lost  (Harris  2008,  498-9). 

Reliance  upon  a  connectionless  protocol  and  its  risk  of  data  loss  might  be 
tactically  acceptable  for  covert  units  if  the  network  pushes  frequent  updates  to  situational 
awareness  data  and  tactical  orders.  In  this  situation,  the  information  lost  due  to  dropped 
packets  can  be  revived  in  the  next  update,  and  the  receiver  can  maintain  an  adequate 
tactical  picture.  This  solution,  however,  would  increase  the  burden  on  tactical  networks 
and  place  them  at  greater  risk  of  overload. 

Network  administrators  would  also  face  the  difficult  task  of  deciding  where  to 
provide  broadcast  coverage  intended  for  these  covert  units.  Transmitting  throughout  the 
entire  network  would  consume  the  available  bandwidth  and  restrict  the  ability  of  the  rest 
of  the  force  to  communicate.  Transmitting  only  in  the  geographic  area  where  the  covert 
units  operate  risks  alerting  enemy  forces  to  the  covert  units’  presence,  and  it  might  not 
even  be  possible  to  arrange  this  type  of  coverage  since  the  most  covert  operations  are 
generally  kept  secret  from  the  mainline  forces.  Administrators  must  carefully  balance  the 
need  for  network  capacity  with  the  need  to  protect  the  secrecy  of  covert  units. 

Covert  units  may  be  able  to  use  Low  Probability  of  Intercept  (LPI) 
communications  methods  to  achieve  some  degree  of  network  participation.  LPI 
communications  are  wireless  data  transmissions  that  are  difficult  for  anyone  but  the 
intended  receiver  to  detect  and  are  also  difficult  to  jam  (Boak  1973,  11).  Typical  LPI 
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technologies  make  use  of  high-frequency  radio  transmissions  using  a  high-gain, 
directional  antenna  (Carmana  2009,  2-AM-82).  Optical  signals  can  be  highly  secure, 
though  they  can  easily  be  blocked  by  clouds  or  smoke. 

Another  operational  security  concern  comes  from  an  adversary’s  ability  to  deduce 
important  tactical  information  from  reading  patterns  in  friendly  communications.  The 
adversary  may  not  be  able  to  decode  and  eavesdrop  on  these  transmissions,  but  through 
analyzing  the  amount  and  location  of  transmissions  they  may  be  able  to  determine  that 
some  significant  action  is  taking  place.  This  aspect  of  operational  security  is  especially 
important  before  hostile  action  has  actually  started,  since  a  spike  in  communications 
activity  can  tip  off  the  enemy  that  a  surprise  attack  is  coming.  Friendly  units  can  avoid 
giving  away  this  type  of  information  by  maintaining  a  constant  level  of  communications 
activity  even  when  the  messages  contain  no  tactical  information,  filling  their  messages 
instead  with  “placeholder”  data  that  is  ignored  by  the  recipient  (Commission  on  Physical 
Sciences,  Mathematics,  and  Applications  2000,  194). 
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VI.  PERSONNEL  SECURITY 


Human  developers,  users,  and  maintainers  form  a  eritieal  part  of  any  military 
system,  and  a  proper  systems  engineering  effort  must  aeeount  for  their  eontributions  and 
limitations.  People  ean  threaten  the  seeurity  of  a  system  intentionally  during  the 
developmental  or  operational  phase  by  eondueting  espionage  or  sabotage.  Even  loyal 
and  well-intentioned  people  ean  eause  seeurity  problems  by  failing  to  follow  seeurity- 
related  proeedures  or  by  falling  vietim  to  soeial  engineering  attaeks.  Developers  must 
eonsider  every  aspeet  of  human  interaetion  and  proteet  against  the  seeurity  risks  that 
people  bring  to  the  system. 

A.  THE  HUMAN  COMPONENT 

Any  network-eentrie  military  system  will  inelude  many  people  to  design,  build, 
maintain,  and  operate  the  hardware  and  software.  The  fields  of  systems  engineering  and 
human  faetors  engineering  have  advaneed  the  eoneept  that  these  people  are  integral  parts 
of  the  system  and  that  any  design  deeisions  must  aeeount  for  their  aetions  and  mistakes. 
As  the  DoD  Office  of  Force  Transformation  stated. 

The  implementation  of  NCW  is  first  of  all  about  human  behavior  as 
opposed  to  information  technology.  Our  focus  should  be  on  human 
behavior  in  the  networked  environment.  How  do  military  forces  behave, 
perform,  and  organize  themselves  when  they  are  networked?  (Office  of 
Force  Transformation  2005,  3) 

Accordingly,  many  security  experts  believe  that  people  are  the  greatest  security  weakness 
in  any  computerized  system.  As  Bruce  Schneier  stated,  “People  often  represent  the 
weakest  link  in  the  security  chain  and  are  chronically  responsible  for  the  failure  of 
security  systems”  (Schneier  2000,  255). 

The  system  life  cycle  includes  human  activities  at  every  stage.  At  system 
inception,  people  execute  the  three  elements  of  the  military’s  procurement  and 
sustainment  system;  the  Planning,  Programming,  Budgeting,  and  Execution  process,  the 
requirements  development  process,  and  the  acquisition  management  process  (DoD  2003). 
Once  this  system  identifies  needs,  allocates  funding,  and  assigns  a  program  manager, 
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other  people  work  to  design  and  build  the  system.  The  fielded  system  then  requires  other 
people  to  operate  and  maintain  the  hardware  and  software  elements  throughout  the 
operational  phase  of  the  system  life  cycle.  Even  at  the  end  of  system  life,  people  are 
needed  to  oversee  the  decommissioning  and  disposal  of  hardware  and  software.  Every 
stage  of  the  system  life  cycle  requires  people  who  must  be  trusted  to  perform  their  role 
properly,  and  the  security  risk  to  the  system  comes  from  people  who  intentionally  or 
accidentally  violate  that  trust. 

In  any  other  aspect  of  security,  technological  methods  can  solve  security 
vulnerabilities  and  reduce  risks.  Rigorous  design  practices  and  thorough  testing 
combined  with  a  process  of  detecting  new  risks  and  quickly  issuing  patches  or  updates 
can  eliminate  most  risks  to  computer  and  network  security.  Meticulous  labeling  of 
information  and  design  of  information  flows  can  eliminate  most  risks  to  information 
security.  Tamper-proofing,  authentication  techniques,  and  hardware  redundancy  can 
boost  physical  security.  EPI  communication  methods  and  connectionless  protocols  can 
provide  operational  security.  However,  because  human  interaction  involves  judgment,  no 
amount  of  technology-based  techniques  and  tools  can,  by  themselves,  bring  the  personnel 
security  risks  to  an  acceptable  level  (Harris  2008,  135).  These  tools  can  reduce  the 
personnel-related  security  risks,  but  designers  must  consider  human  fallibility  and 
incorporate  procedures  that  anticipate  the  most  likely  human  failures  and  minimize  their 
likelihood  and  impact.  As  Bruce  Schneier  stated,  “Mathematics  is  logical;  people  are 
erratic,  capricious,  and  barely  comprehensible”  (Schneier  2000,  xii). 

Given  the  need  for  trusted  human  interactions  in  any  complex  system,  designers 
must  consider  the  ways  that  people  can  introduce  security  problems.  People  can  cause 
security  violations  intentionally  or  accidentally.  The  intentional  violations,  espionage 
and  sabotage,  are  the  easiest  to  understand.  Accidental  violations,  however,  can  come 
from  a  wide  variety  of  behaviors  and  situations  and  often  involve  a  trade-off  between 
security  and  functionality.  Designers  must  weigh  the  need  for  security  with  the 
efficiency,  reliability,  and  ease  of  use  of  systems  and  provide  both  technological  features 
and  operational  procedures  to  achieve  an  acceptable  level  of  risk. 
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B,  INTENTIONAL  SECURITY  VIOLATIONS 

The  need  to  include  fallible  and  unpredictable  humans  as  critical  components  of 
complex  systems,  introduces  the  risk  that  some  of  those  people  may  be  working  for  the 
enemy  as  spies  or  saboteurs.  These  people,  whether  they  sympathize  with  the  enemy  or 
simply  want  fast  cash  and  an  exciting  line  of  work,  can  give  sensitive  information  to  the 
enemy,  inject  false  information  into  the  network,  and  cause  equipment  failures  and 
communication  outages.  The  immense  complexity  of  a  network-centric  system  can  help 
these  malicious  insiders  disguise  their  actions  and  avoid  detection.  This  malicious  action 
can  take  place  during  system  development  and  during  the  operation  and  support  phase  of 
the  system  life  cycle. 

1,  Developmental  Stage  Security 

During  the  developmental  stage,  enemy  agents  can  collect  system  design  and 
configuration  information  and  leak  it  to  hostile  forces.  The  improvements  in  digital 
information  storage  technology  have  made  espionage  easier  and  more  efficient  than  it 
was  in  the  days  of  the  cold  war,  and  vast  quantities  of  information  can  be  copied  onto 
flash-memory  devices  and  smuggled  out  of  the  building.  These  devices,  including 
Universal  Serial  Bus  (USB)  thumb  drives,  memory  cards,  portable  hard  drives,  cell 
phones,  and  digital  media  players,  will  successfully  interface  with  the  computer  hardware 
used  in  many  development  environments  since  the  devices  and  hardware  both  conform  to 
the  same  commercial  open-architecture  interface  standards.  Armed  with  detailed  design 
and  configuration  information,  potential  adversaries  can  search  for  system  weaknesses 
and  develop  customized  attacks  for  use  if  a  conflict  emerges.  States  and  trans-national 
organizations  not  directly  involved  in  a  conflict  with  the  U.S.  can  provide  these  attack 
methods  to  those  groups  actually  doing  the  fighting  as  “off-the-shelf’  tools  ready  for 
immediate  use  (Commission  on  Physical  Sciences,  Mathematics,  and  Applications  2000, 
177). 

Thefts  of  technical  data  may  result  from  industrial  espionage  in  addition  to  the 
nationally  sponsored  spying  conducted  for  military  purposes.  American  technology 
companies  face  a  significant  threat  of  espionage  from  foreign  companies,  some  of  whom 
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are  assisted  by  their  governments  (Epstein  2008).  If  advanced  technology  information  is 
stolen  by  a  foreign  entity,  it  may  be  sold  to  other  companies  and  governments  and  used  to 
create  competitive  products  and  to  design  the  same  customized  attacks  made  possible 
from  government-sponsored  espionage.  Secretary  of  Defense  Robert  Gates,  describing 
the  threat  from  industrial  sabotage,  said. 

In  a  world  that  increasingly  measures  power  in  economic  as  well  as 
military  terms,  many  foreign  intelligence  services  are  turning  their  sights 
to  stealing  American  technology  and  trade  secrets.  Some  countries  with 
whom  we  have  had  good  relations  may  adopt  a  two-track  approach, 
cooperating  with  us  at  the  level  of  diplomacy  while  engaging  in 
adversarial  intelligence  collection.  (Nolan  2000,  1) 

China  presents  a  particular  threat  of  industrial  espionage.  They  have  a  long 
history  of  reverse  engineering  and  commonly  use  it  to  match  competitor’s  products  and 
build  new  military  hardware.  While  military-developed  products  would  require  some 
degree  of  espionage,  the  commercial  products  that  often  form  the  foundation  of  military 
systems  can  be  acquired  simply  by  purchasing  them  (Fritz  2008,  33). 

Enemy  agents,  commercial  spies,  and  disgruntled  employees  can  also  pose  a 
sabotage  threat.  Major  software  projects  can  be  so  complex  that  a  small  but  malicious 
change  in  a  code  library  may  go  unnoticed.  These  changes  can  include  back-door  access 
points  that  can  allow  system  access  without  proper  authentication,  logic  bombs  that 
degrade  system  performance  or  cause  data  errors  when  the  system  is  used  operationally, 
or  covert  channels  that  leak  sensitive  information  without  proper  encryption  or 
classification-checking  controls.  Both  espionage  and  sabotage  by  insiders  share  features 
that  cause  the  event  to  take  place  and  that  help  it  happen  successfully  (Band  et  al.  2006, 
vii). 

Defending  security  during  system  development  requires  the  standard  tools  used  in 
government  and  commercial  office  settings.  People  must  pass  background  checks  and 
hold  an  appropriate  security  clearance  before  being  granted  access  to  sensitive  material. 
Administrators  of  the  development  system  should  remove  any  access  points  for  digital 
media  not  needed  for  development  work,  including  USB  ports,  CD  and  DVD  recorders, 
and  card  readers.  Systems  can  also  use  software  applications  at  the  workstation  and 
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network  level  to  monitor  information  flow  over  the  network  and  detect  suspicious  actions 
from  users.  Network  operations  should  be  thoroughly  logged,  where  the  system  records 
each  operation  in  a  log  file,  so  security  personnel  can  recognize  security  violations  and 
identify  the  personnel  responsible.  Code  submitted  to  production  libraries  must  be 
inspected  and  understood  by  more  than  its  author.  All  these  security  measures  will  add  to 
the  cost  of  development,  but  managers  must  resist  the  temptation  to  raid  the  security 
budget  to  make  up  for  development  cost  overruns. 

The  background  checks  and  security  clearances,  while  helpful  for  screening  out 
people  with  known  suspicious  connections  and  activities,  cannot  predict  anyone’s  future 
activities  or  accurately  judge  a  person’s  true  intentions  and  loyalties.  Program  managers 
must,  therefore,  resist  the  temptation  to  downplay  the  likelihood  of  insider  attacks  simply 
because  all  the  insiders  have  survived  some  vetting  process.  Bruce  Schneier,  discussing 
the  futility  of  using  terrorist  watch  lists  to  prevent  terrorist  attacks,  points  out  how 
identity  cannot  be  correlated  with  intent: 

But  even  if  these  [terrorist  watch]  lists  were  complete  and  accurate,  they 
wouldn't  work.  Timothy  McVeigh,  the  Unabomber,  the  D.C.  snipers,  the 
London  subway  bombers  and  most  of  the  9/11  terrorists  weren't  on  any  list 
before  they  committed  their  terrorist  acts.  In  the  end,  the  photo  ID 
requirement  is  based  on  the  myth  that  we  can  somehow  correlate  identity 
with  intent.  We  can't.  And  instead  of  wasting  money  trying,  we  would  be 
far  safer  as  a  nation  if  we  invested  in  intelligence,  investigation,  and 
emergency  response  —  security  measures  that  aren't  based  on  a  guess 
about  a  terrorist  target  or  tactic.  (Schneier  2008b) 

2.  Operational  Stage  Security 

During  system  operations,  administrators  have  the  power  to  attack  the 
confidentiality,  integrity,  and  availability  of  the  network  and  its  data.  The  specific  role 
and  duties  of  these  administrators  depends  upon  the  system  design,  but  some  degree  of 
human  intervention  and  supervision  will  be  required  for  any  type  of  system. 
Administrators  could  possibly  link  a  covert  enemy  unit  to  the  network,  providing  that  unit 
with  the  locations,  status,  and  orders  of  the  entire  friendly  force  as  well  as  the  complete 
description  of  sensor  contacts  and  knowledge  about  the  opposing  force.  They  could  mis- 
configure  encryption  settings  to  allow  some  part  of  the  network  to  transmit  its 
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information  in  the  clear  where  it  could  be  intercepted  by  hostile  units.  They  could  attack 
the  integrity  of  the  network  by  directly  editing  data,  changing  friendly  units  to  appear 
hostile,  deleting  enemy  units  from  sensor  reports,  or  creating  bogus  hostile  units  to  serve 
as  a  diversion.  They  could  also  damage  the  system’s  availability  by  removing  friendly 
units  from  the  network  or  shutting  down  the  network  itself. 

The  use  of  contractors  to  perform  administrative  and  technical  duties  presents  a 
special  risk  because  military  supervisors  have  less  ability  to  screen  and  manage 
contractor  personnel.  Unable  to  build  technical  expertise  in-house,  some  companies,  and 
government  and  military  organizations  rely  on  contractors  and  run  the  risk  of  becoming 
dependent  upon  them.  As  an  example  of  the  risk  that  comes  with  contracted  information 
technology  (IT)  administration,  the  World  Bank  recently  experienced  several  major 
penetrations  in  their  highly  sensitive  treasury  unit.  The  FBI  discovered  that  spyware  had 
been  installed  on  servers  and  suspected  that  contractor  personnel,  who  performed  nearly 
all  the  bank’s  IT  services,  were  the  culprits.  The  bank  terminated  the  contract  with  the 
company  but  found  itself  unable  to  operate  without  the  contractor  personnel  because  bank 
personnel  lacked  enough  knowledge  about  the  system  to  be  able  to  operate  it  themselves. 
As  a  result,  many  of  the  contractors  continued  to  work,  either  as  employees  of  the 
replacement  company  or  as  newly  hired  bank  staff.  The  perpetrators  were  never 
discovered  and  the  bank  cannot  be  certain  that  they  are  not  still  working  there  in  sensitive 
positions  (Behar  2008). 

To  protect  their  security  from  personnel-related  risks,  operational  network-centric 
systems  can  borrow  some  of  the  practices,  such  as  two-person  control  and  controlled 
access,  that  are  used  by  high-security  programs.  The  two-person  control  concept  aims  to 
make  it  impossible  for  one  person  to  sabotage  the  system  without  their  actions  being 
discovered,  reported,  and  corrected  (Commission  on  Physical  Sciences,  Mathematics,  and 
Applications  2000,  178).  Administrative-level  access  to  the  system,  at  least  in  areas  that 
can  damage  confidentiality,  integrity,  and  availability,  should  require  the  direct  attention 
of  at  least  two  trained  administrators.  This  requirement  must  be  more  than  a  procedural 
requirement;  the  administrative  software  function  should  control  access  by  requiring 
valid  access  credentials  from  two  or  more  qualified  personnel.  Once  the  participants  are 
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identified  and  authenticated,  the  second  person  must  observe  the  actions  of  the  person 
actually  operating  the  system  and  have  the  ability  to  stop  the  changes  before  they  are 
promulgated  to  the  system.  Defeating  this  security  measure  would  require  collusion 
between  the  two  administrators,  a  highly  unlikely  situation  that  would  be  considered  an 
acceptable  risk  (Harris  2008,  136). 

Logging  of  administrative  actions  is  just  as  important  to  the  operational  system  as 
it  is  in  the  developmental  environment.  Administrators  must  access  the  system  with 
unique  user  identification  and  authentication,  preferably  using  two-factor  authentication 
including  a  physical  token  such  as  a  smart  card.  Given  this  strict  authentication,  every 
administrative  action  can  be  recorded  along  with  the  identity  of  the  person  who  took  the 
action.  Careful  log  reviews  may  then  detect  suspicious  actions  or  outright  security 
violations  and  identify  the  responsible  party.  To  ensure  that  the  logging  system  remains 
effective,  it  must  be  designed  such  that  the  log  file  cannot  be  altered  and  the  logging 
function  cannot  be  switched  off  or  bypassed  (Harris  2008,  245-6). 

C.  ACCIDENTAL  SECURITY  VIOLATIONS 

Security  violations  caused  by  loyal  and  well-intentioned  operators  can  cause 
damage  similar  to  that  done  by  spies  and  saboteurs.  Some  people  may  be  tricked  by 
social  engineering  attacks  into  revealing  secret  information  or  granting  system  access  to 
enemy  agents.  Others  may  ignore  security  rules  in  order  to  boost  productivity.  Unlike 
the  case  with  intentional  violations,  these  accidental  events  reveal  systemic  weaknesses 
that  often  require  broad  countermeasures  to  combat  and  may  never  be  fully  preventable. 

1.  Social  Engineering 

Some  of  the  most  notorious  computer  hackers,  like  Kevin  Mitnick,  found  social 

engineering  to  be  a  more  efficient  method  of  penetrating  computer  system  security  than 

technological  attacks  (Schneier  2000,  267).  He,  and  many  others,  used  fraud  and 

deception  to  trick  trusted  insiders  into  revealing  secret  information  or  allowing  him  to 

access  restricted  parts  of  the  system.  This  type  of  attack  can  be  used  against  any  type  of 

organization  or  system  that  includes  people  and  is  not  restricted  to  computer-based  or 

network-centric  systems;  however,  they  can  prove  especially  effective  against  computer- 
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based  systems  beeause  of  the  inherent  value  of  information  like  passwords  and 
eonfiguration  settings  and  the  damage  that  an  attacker  can  cause  when  sensitive 
information  is  leaked. 

Social  engineering  uses  the  ancient  arts  of  fraud  and  deception  to  prey  upon  the 
fundamental  characteristics  of  human  nature.  Most  people  want  to  be  appreciated  and 
will  be  tempted  to  bend  the  rules  to  help  someone  they  believe  deserves  assistance  and 
will  show  them  appreciation  (Schneier  2000,  268).  People  also  tend  to  view  authority 
figures  with  a  mixture  of  fear  and  respect  and  may  yield  to  the  demands  of  someone 
impersonating  an  authority  figure.  Others  simply  wish  to  avoid  conflict  and  may  provide 
information  or  access  to  someone  demanding  it  in  order  to  get  the  person  to  leave.  Some 
people  may  fall  victim  to  their  own  greed  and  break  security  rules  in  return  for  some 
tangible  benefit,  though  this  act  would  generally  propel  the  “victim”  into  the  category  of 
a  spy  or  saboteur  and  not  a  well-intentioned  dupe. 

Compounding  the  vulnerability  to  social  engineering  attacks  is  the  fact  that  people 
are  often  very  good  at  self-deception.  They  sometimes  substitute  wishful  thinking  and 
naive  assumptions  for  a  sober  analysis  of  the  situation  and  the  risks  of  breaking  the  rules 
(Paul,  Niewoehner,  and  Elder  2007,  49).  People  may  fail  to  consider  the  risks  of 
divulging  sensitive  information  or  to  rigorously  authenticate  the  people  requesting  this 
information  because  of  the  subconscious  assumption  that  everything  will  end  well 
because  it  has  in  the  past. 

Defense  against  the  social  engineering  attack  relies  on  security  training,  the 
creation  of  a  security-centered  culture,  and  the  enforcement  of  the  principle  of  least 
privilege.  The  training  exposes  personnel  to  the  concept  of  the  social  engineering  attack 
and  to  the  techniques  that  attackers  use  to  get  information  and  access.  It  establishes 
authentication  requirements  that  personnel  must  enforce  on  anyone  seeking  information 
or  access  and  it  shows  the  consequences  of  failing  to  properly  authenticate  someone. 
Training  provides  little  benefit  by  itself,  but  it  creates  the  intellectual  foundation  for  the 
security  culture  needed  to  ensure  that  the  secure  procedures  and  practices  are  actually 
followed. 
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A  robust  culture  of  security  within  an  organization  ensures  that  the  information 
learned  in  training  is  consistently  and  correctly  put  to  use.  Supervisors  must  demonstrate 
through  word  and  action  the  importance  of  security.  They  must  conspicuously  enforce 
security  procedures  and  make  security  practices  an  important  part  of  personnel 
evaluations,  including  awards  and  disciplinary  actions.  They  must  also  accept  that 
security  practices  necessarily  reduce  productivity  and  ensure  that  personnel  are  never 
pressured  to  take  shortcuts  in  order  to  meet  an  urgent  deadline  or  production  goal. 
Finally,  senior  personnel  must  set  the  example  and  scrupulously  follow  the  security  rules 
themselves.  This  last  point  may  be  the  most  difficult  from  a  cultural  perspective,  since 
senior  personnel  typically  enjoy  exemptions  from  policies  that  apply  to  rank-and-file 
personnel  (e.g.,  reserved  parking  space,  administrative  support);  however,  it  is  vital  that 
security  practices  and  rules  are  perceived  as  being  a  legitimate  precaution  that  applies 
across  the  board,  and  not  simply  an  indication  of  rank  and  status. 

System  developers  and  administrators  can  also  use  technological  means  to  help 
reduce  the  risk  of  social  engineering  attacks  (Schneier  2000,  268).  Although  hardware 
and  software  tools  cannot  prevent  personnel  from  divulging  information  or  granting 
access  to  an  attacker,  they  can  reduce  the  damage  inflicted  by  such  an  error.  System 
administrators  must  vigorously  apply  the  principle  of  least  privilege  and  only  allow 
personnel  to  access  information  and  systems  they  need  for  their  duties. 
Compartmentalizing  information  in  this  manner  ensures  that  few  personnel  have  the 
ability  to  give  away  “the  keys  to  the  kingdom”  and  that  compromises  of  data  and  access 
damage  only  the  area  under  the  victim’s  immediate  control.  Other  technological  tools 
that  can  help  organizations  resist  social  engineering  attacks  are  those  that  allow  personnel 
to  reliably  authenticate  anyone  asking  for  information  or  access.  For  example,  use  of 
digital  signatures  on  emails  reduce  the  risk  that  an  attacker  can  impersonate  someone 
inside  the  organization  and  extract  information  from  an  unwitting  co-worker. 

2.  Security  Procedures 

Any  system  with  human  operators  will  likely  require  some  kind  of  operator  action 
to  maintain  the  security  of  the  system.  Such  actions  may  include  activating  an  encrypted 
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channel  or  using  a  low-probability-of-intercept  method  of  communications.  The  system 
and  component  design  will  determine  what  operator  actions  are  available  and  necessary 
for  security.  This  design  may  foree  operators  to  operate  in  a  secure  mode  by  disallowing 
any  other  option,  or  it  may  provide  greater  operational  flexibility  but  rely  on  operators  to 
make  the  most  prudent  choice. 

A  well-designed  network-centrie  weapon  system  would  naturally  rely  far  less 
upon  operator  actions  to  maintain  security  than  a  typical  computer  network  used  for 
offiee  automation  or  electronic  commerce.  Commereial  systems,  in  particular,  must 
remain  open  to  a  wide  variety  of  un-authentieated  users  with  hardware  and  software 
operating  aceording  to  open  arehitecture  standards.  Even  if  the  sensitive  parts  of  the 
system  use  authentieation  and  other  seeurity  measures,  the  open  and  less-proteeted 
interfaee  to  the  general  public  allows  attackers  an  avenue  to  gain  access  and  work  their 
way  into  the  protected  areas.  In  contrast,  a  network-centric  military  system  has  no  need 
to  allow  access  to  anyone  but  an  authorized  user  who  ean  prove  his  identity  and  will  use 
specific  hardware,  software,  and  protocols  to  gain  access.  Therefore,  the  military  system 
ean  often  use  technological  countermeasures  to  provide  security  and  prohibit  operator 
aetions  that  introduce  seeurity  risks. 

The  system  design  may  provide  some  method  of  bypassing  or  overriding  security 
procedures  for  operation  during  an  emergency  when  the  normal  procedures  are  infeasible. 
For  example,  a  radio  may  allow  operators  to  establish  an  unenerypted  conneetion  if  the 
authentication/eneryption  proeess  fails  and  the  operator  has  an  urgent  need  to 
communicate.  Such  flexibility  could  improve  the  reliability  of  the  networking  equipment 
and  provide  a  backup  method  of  operation,  preventing  a  failure  of  a  security-related 
function  from  automatically  becoming  a  failure  of  the  entire  network.  The  degree  of 
freedom  given  to  operators  to  perform  this  seeurity  override  will  depend  upon  the  system 
design,  but  any  design  will  rely  upon  the  operator’s  security-related  actions  to  some 
degree. 

While  providing  the  ability  to  operate  in  a  less-seeure  eonfiguration  may  improve 

reliability,  it  also  counts  on  the  operator’s  judgment  to  only  operate  in  this  manner  when 

necessary.  Unfortunately,  operators  may  laek  a  sufficient  understanding  of  and 
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appreciation  for  security  and  may  start  bypassing  security-related  procedures  to  improve 
productivity  and  ease  of  use.  Pressured  to  “Just  get  it  done,”  some  operators  may  view 
security  rules  as  unnecessary  obstacles  and  avoid  them,  opening  a  vulnerability  that  can 
be  exploited  by  a  hostile  force.  The  high  turnover  in  the  military  and  the  life-and-death 
tactical  concerns  mean  that  security  knowledge  may  be  a  low  priority  for  operators. 

Protecting  system  security  from  this  abuse  of  operator  discretion  requires  actions 
similar  to  those  needed  to  protect  against  the  social  engineering  attack.  Operators  must 
be  trained  on  the  importance  of  secure  operation  and  the  risks  of  taking  shortcuts. 
Supervisors  must  set  clear  standards  on  secure  operating  practices  and  consistently 
enforce  them  while  setting  the  example  through  their  own  behavior.  The  system  should 
log  all  non-standard  operations  to  help  supervisors  enforce  the  standards  and  understand 
the  real-world  use  of  the  system. 

Developers  must  also  understand  what  kinds  of  personnel-related  attacks  on  the 
system  work  and  why.  Users  sometimes  disregard  security  indicators  and  focus  on 
content,  particularly  when  warnings  are  over-used  due  to  system  mis-configurations  or 
software  errors.  Therefore,  the  system  must  not  rely  upon  users  to  seek  out  security 
indicators  and  scrupulously  obey  security  warnings.  Even  security-conscious  users  can 
be  fooled  by  visual  deception  attacks  that  create  false  security  indicators  to  mask 
malicious  activity  (Dhamija,  Tygar,  and  Hearst  2006,  3). 
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VII.  WHOLE  SYSTEM  SECURITY 


As  the  previous  ehapters  have  explained,  attaeks  on  the  seeurity  of  network- 
eentrie  military  systems  ean  take  a  wide  variety  of  forms.  Foeusing  seeurity  efforts  only 
on  one  aspeet — eomputer  and  network  seeurity,  for  example — would  leave  the  system 
vulnerable  to  unexpeeted  attaeks  from  other  avenues.  Aeeording  to  Arthur  Cebrowski, 

Implementation  of  NCW  must  look  beyond  the  aequisition  of  the  teehnieal 
enablers  to  individual  and  organizational  behavior,  e.g.,  organizational 
strueture,  proeesses,  taeties,  and  the  way  ehoiees  are  made.  In  other  words, 
all  elements  of  the  enterprise  are  in  play.  (Offiee  of  Foree  Transformation 
2000,  i) 

System  developers  must  embraee  a  systems  engineering  approaeh  to  seeurity  and 
eonsider  all  the  threats  and  vulnerabilities  faeing  the  system  in  the  larger  eontext  of  its 
operational  environment.  This  examination  must  inelude  not  only  the  teehnieal 
eharaeteristies  of  the  eomponents  but  also  the  people  who  operate  and  maintain  the 
system,  the  support  elements  that  keep  the  system  running,  and  the  environment  in  whieh 
the  system  will  operate.  As  Bruee  Sehneier  noted  when  discussing  cryptography. 

The  weak  points  had  nothing  to  with  mathematics.  They  were  in  the 
hardware,  the  software,  the  networks,  and  the  people.  Beautiful  pieces  of 
mathematics  were  made  irrelevant  through  bad  programming,  a  lousy 
operating  system,  or  someone’s  bad  password  choice.  (Sehneier  2000,  xii) 

Once  they  identify  the  system-level  risks  and  create  security  requirements  to  address 
those  risks,  the  engineers  can  allocate  those  requirements  into  detailed  features  and 
characteristics  that  meet  the  system’s  needs. 

The  systems-based  approach  applies  even  within  security  domains  such  as 
computer  and  network  security.  Adversaries  may  avoid  the  highly  protected  tactical 
network  and  focus  their  efforts  on  less-protected  areas  such  as  logistics  systems.  These 
lower-profile  systems  can  provide  both  an  entry  point  into  tactical  systems  and  a  source 
of  information  that  can  infer  the  movements,  status,  and  intentions  of  friendly  forces.  For 
example,  seemingly  innocent  information  on  logistics  preparations  and  reconnaissance 
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operations  can  signal  the  timing  of  an  attack  (Boak  1973,  4).  Furthermore,  it  may  be 
possible  to  defeat  the  entire  system  by  crippling  its  supporting  infrastructure.  According 
to  John  Tkacik, 

The  Chinese  military  doctrine  stresses  the  importance  of  penetrating  an 
adversary's  military  logistics  and  personnel  networks.  Furthermore,  the 
multiple  intrusions  into  what  nuisance  and  criminal  hackers  would  regard 
as  boring,  mundane  networks  —  networks  that  do  not  offer  the  treasure 
trove  of  credit  card  numbers,  bank  accounts,  and  identity  data  that 
criminal  hackers  typically  seek  —  suggest  a  military  purpose.  (Tkacik 
2008,  3) 

Given  that  the  number  and  types  of  risks  are  virtually  unlimited  and  that  the 
resources  to  mitigate  those  risks  are  highly  constrained,  the  other  task  for  systems 
engineers  is  to  evaluate  the  relative  efficiency  of  security-related  attacks  and  apply  the 
development  effort  to  combat  the  most  likely  and  effective  attacks.  This  task  requires  a 
great  deal  of  judgment  since  the  risks  tend  to  be  subjective  and  speculative,  but  a  detailed 
failure  analysis  study  combined  with  close  attention  to  real-world  security  violations  in 
computer-intensive  systems  should  help  developers  quantify  the  risks  and  assign  a 
relative  priority. 

Developers  must  also  indirectly  boost  the  security  of  the  system  by  making  the 
design  as  simple  as  possible.  According  to  Bruce  Schneier, 

Complexity  is  the  worst  enemy  of  security.  As  systems  get  more  complex, 
they  necessarily  get  less  secure.  (Schneier  2000,  1) 

Simpler  systems  enjoy  greater  security  because  of  the  reduced  number  of  opportunities  to 
attack  the  system  through  unexpected  inputs  or  configurations.  They  present  an  easier 
management  task  for  administrators  and  operators,  reducing  the  likelihood  of  inadvertent 
security  violations.  They  also  make  easier  subjects  for  technical  evaluation,  allowing  a 
more  thorough  analysis  and  a  more  confident  declaration  of  the  security  of  the  design. 

The  security  problems  brought  about  by  complexity  may  be  especially  difficult 
for  a  network-centric  weapon  system.  Such  a  system  will  likely  be  formed  from  a  wide 
variety  of  components,  each  optimized  for  the  special  requirements  of  the  forces  and 
commanders  using  them.  Current  methods  may  provide  an  assurance  that  each 
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component  can  operate  securely,  but  this  assurance  does  not  extend  to  each  combination 
of  components  operating  together  in  a  tactical  network.  The  problem  compounds  even 
more  when  systems  of  allied  nations  join  the  network.  Managing  this  complexity 
requires  the  creation  of  a  security  architecture  that  specifies  the  components  of  the  system 
and  their  interactions.  This  architecture  simplifies  the  task  of  security  analysis  by 
allowing  developers  to  operate  at  a  high  level  of  abstraction  with  regard  to  system 
elements. 

A.  TEST  AND  EVALUATION 

Once  the  developers  complete  a  preliminary  design  of  the  system,  they  can  use 
penetration  testing  to  discover  overlooked  vulnerabilities.  This  kind  of  testing  uses  a  “red 
team”  of  creative  people  who  have  significant  training  and  experience  in  attacking 
networked  systems  to  attack  the  system  and  record  the  outcome  of  their  efforts.  To  be 
effective,  this  testing  should  impose  as  few  constraints  as  possible  on  the  team.  The  team 
should  be  given  general  information  about  the  system  and  its  configuration,  especially  if 
the  system  uses  commercial  components,  in  an  effort  to  best  simulate  an  attack  from  a 
sophisticated  foreign  power.  They  should  work  not  only  to  attack  the  system  but  also  to 
find  novel  ways  of  circumventing  the  security-related  countermeasures.  Even  the  most 
rigorous  penetration  testing  cannot  detect  all  possible  vulnerabilities,  however,  since  the 
number  of  possible  attacks  is  essentially  infinite  and  since  a  real  attacker  may  conceive  of 
an  attack  method  unimagined  and  untested  by  the  red  team  (Harris  2008,  1090-8). 

This  penetration  testing  effort  can  be  part  of  the  larger  developmental  testing 
effort.  Developmental  testing,  as  described  in  DoD  Instruction  5000.02,  subjects  the 
system  to  a  set  of  planned,  controlled,  and  complete  scenarios  to  verily  that  the  security 
functions  operate  properly.  Since  this  testing  takes  place  in  a  controlled  environment  and 
is  conducted  by  developmental  personnel,  it  can  methodically  exercise  a  wide  range  of 
inputs  and  configurations  to  discover  vulnerabilities  not  adequately  mitigated  by  the 
security  functions.  This  testing  starts  at  the  component  level  and  works  its  way  outward 
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to  larger  portions  of  the  system,  eventually  ineluding  scenarios  that  capture  the  unique 
needs  of  information,  physical,  operational,  and  personnel  security  as  well  as  interactions 
among  them. 

Developers  must  also  conduct  operational  testing  to  measure  the  demand  placed 
upon  users  by  the  security  functions  and  requirements  for  computer  and  network, 
information,  physical,  operational,  and  personnel  security.  This  testing  uses  real 
operators  and  operationally  representative  environments  to  simulate  the  function  of  the 
system  in  a  combat  situation.  Part  of  this  testing  should  measure  the  time,  effort,  and 
skill  needed  to  operate  securely,  comparing  those  metrics  with  the  system  configured  to 
operate  without  the  security  features  and  calculating  the  difference.  Testing,  including 
comments  from  operators,  will  reveal  those  specific  functions  or  procedures  that  impose 
a  significant  operational  penalty.  Developers  can  then  evaluate  the  relative  cost  and 
benefit  of  each  security  function  and  procedure  and  either  improve  or  remove  the  ones 
that  impose  a  cost  far  greater  than  their  value  to  security.  Operational  testing  should  also 
include  a  red  team  effort  to  compromise  the  system  in  a  less  predictable  and  controlled 
environment,  providing  one  more  opportunity  to  discover  novel  and  unexpected 
vulnerabilities  and  attack  techniques. 

There  is  an  important  distinction  between  functional  testing  and  security  testing 
(as  introduced  in  Chapter  II),  though  both  are  required  to  provide  a  reasonable  assurance 
that  the  system  will  function  properly  and  securely.  Functional  testing  steps  through  all 
the  usage  scenarios,  simulating  the  users,  interfacing  systems,  and  inputs  for  each 
scenario.  It  verifies  that  the  system  will  correctly  process  inputs  from  users  and  other 
systems  and  react  as  intended  without  crashing  or  providing  erroneous  data.  It  also 
ensures  that  the  user  interface  is  adequate  to  allow  users  to  operate  the  system  without 
confusion,  delay,  or  error.  The  Joint  Interoperability  Test  Command,  part  of  the  Defense 
Information  Systems  Agency,  plays  a  major  role  in  functional  testing  of  networked 
systems. 

In  contrast,  the  security  testing  considers  the  ways  that  an  attacker  might  attempt 

to  compromise  the  system.  It  considers  the  wide  variety  of  unusual  or  unexpected  inputs 

that  might  place  the  system  in  an  insecure  state.  Since  there  exists  a  nearly  infinite 
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combination  of  unexpected  inputs,  eonfigurations,  and  eonditions,  seeurity  testing  cannot 
guarantee  seeure  operation  the  way  that  functional  testing  ean  guarantee  proper  operation. 
This  is  why  security  testing  must  eonsider  the  most  effieient  attaek  methods,  whether 
from  the  fields  of  eomputer,  network,  information,  physieal,  operational,  or  personnel 
seeurity,  and  apply  testing  effort  toward  vulnerabilities  judged  most  likely  to  be  exploited 
in  an  attaek. 

B,  CERTIFICATION  AND  ACCREDITATION 

While  testing  provides  a  degree  of  teehnieal  assuranee  that  the  system  will 
funetion  as  designed  and  will  be  both  effeetive  and  suitable  for  eombat  use,  the 
eertifieation  and  aeereditation  proeess  provides  a  parallel  effort  to  judge  the  seeurity  of 
the  system  and  ensure  that  systems  are  only  operated  if  their  seeurity  risk  is  redueed  to  an 
aeeeptable  level.  The  DoD  eurrently  uses  the  Defense  Information  Assurance 
Certifieation  and  Aeereditation  Program  (DIACAP),  as  defined  in  DoD  Instruction 
8510.01,  to  perform  this  funetion  and  to  establish  eonfiguration  management  proeesses 
for  seeurity  functions.  In  this  context,  certification  refers  to  technical  evaluation  of  an 
information  system  that  determines  how  well  the  system  eomplies  with  its  required 
Information  Assuranee  (lA)  eontrols.  Aeereditation  refers  to  the  granting  of  permission 
to  operate  and  aeeeptanee  of  risk  by  a  designated  aeerediting  authority  (DAA). 

The  DIACAP  applies  to  DoD  information  systems  and  is  most  applieable  to 
offiee-automation  systems  using  standard  commereial  hardware,  software,  and  protoeols. 
Aeeording  to  DoD  Directive  8500. 02E,  DIACAP  applieability  extends  to  platform  IT 
interoonneetions.  Platform  IT  refers  to  the  hardware  and  software  in  speeial-purpose 
systems  sueh  as  weapons,  simulators,  test  and  maintenanee  equipment,  and  researeh  and 
development  equipment.  The  DIACAP  does  not  apply  to  the  platform  IT  itself,  but  only 
to  its  network  conneetion.  This  boundary  in  the  DIACAP  between  the  weapon  system 
and  its  network  eonneetion  works  well  for  legaey  weapon  systems  where  the  network 
eonneetions  are  limited  in  scope;  however,  network-eentrie  weapon  systems  will  feature  a 
highly-integrated  network  eonneetion  and  will  be  designed  with  network  funetionality  as 
a  top  priority.  The  seeurity  features  of  a  network-eentrie  weapon  system  will  span  every 


67 


aspect  of  its  operation,  not  just  the  network  interface.  Therefore,  the  DIACAP  will 
require  either  significant  additional  guidance  or  a  revision  before  it  can  be  applied  to 
network-centric  systems. 

DIACAP  applicability,  along  with  that  of  the  entire  DoD  lA  program  described  in 
DODD  8500. 02E,  does  not  extend  to  intelligence  systems.  The  intelligence  community 
has  its  own  certification  and  accreditation  program,  described  in  ICD  503.  Significant 
elements  of  a  network-centric  system,  including  unmanned  sensors,  satellites,  and 
reconnaissance  platforms,  as  well  as  the  analysts  and  commanders  who  use  the 
information  provided  by  these  elements,  may  fall  under  ICD  503  for  their  certification 
and  accreditation.  The  fact  that  two  separate  programs  will  be  responsible  for  different 
parts  of  the  overall  system  strains  the  cohesion  of  the  system  and  threatens  to  prolong  the 
legacy  philosophy  of  independent  systems.  If  intelligence-gathering  platforms  are  to  be 
included  in  the  network-centric  system  of  the  future,  this  split  responsibility  could  greatly 
complicate  the  system’s  development. 

The  DIACAP  assigns  lA  controls  to  information  systems  according  to  the  level  of 
confidentiality,  integrity,  and  availability  needed  by  the  particular  system.  These  controls 
include  elements  of  computer  and  network  security,  information  security,  physical 
security,  and  personnel  security.  Operational  security  concerns  are  handled  separately  in 
publications  about  tactical  doctrine  and  do  not  contribute  any  lA  controls.  DoD 
Instruction  8500.2,  “Information  Assurance  Implementation,”  lists  controls  grouped  into 
the  following  subject  areas:  continuity,  enclave  boundary  defense,  enclave  computing 
environment,  identification  and  authentication,  personnel,  physical  and  environmental, 
security  design  and  configuration,  and  vulnerability  and  incident  management. 

Early  in  their  development,  information  systems  receive  two  designations  that 

determine  which  lA  controls  will  apply.  The  Confidentiality  Eevel  (CE)  of  classified, 

sensitive,  or  public  describes  the  sensitivity  level  of  the  information  processed  by  the 

system  and  the  degree  of  protection  that  must  be  applied  to  prevent  attackers  from 

learning  this  information.  The  Mission  Assurance  Category  (MAC)  combines  the 

integrity  and  availability  needs  of  the  system  and  describes  the  degree  of  protection 

needed  to  ensure  that  the  system’s  information  is  correct  and  accessible.  Systems 
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handling  vital  information  for  operational  forces  receive  MAC  I,  systems  handling 
important  information  for  supporting  missions  receive  MAC  II,  and  systems  handling 
day-to-day  business  information  receive  MAC  III.  Each  CL  and  each  MAC  has  a 
separate  attachment  to  enclosure  4  of  DODI  8500.2  containing  the  required  security 
controls,  so  all  systems  will  use  two  of  the  six  attachments  to  get  the  complete  list  of 
required  controls. 


69 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


70 


VIII.  CONCLUSION 


This  thesis  has  explored  the  seeurity  of  network-eentrie  weapon  systems  by 
deseribing  the  different  sourees  of  seeurity  risks  and  by  explaining  the  importanee  of  a 
systems  engineering  approaeh.  Developers  and  poliey  makers  must  keep  seeurity 
eoneerns  in  mind  as  they  bring  new  network-eentrie  systems  to  the  warfighters.  Part  of 
this  eonsideration  ineludes  weighing  the  applieability  of  network-eentrie  systems  to 
eurrent  and  future  operations  and  building  the  eommunieations  tools  to  provide  the 
foundation  for  the  future  network. 

A.  APPLICABILITY  TO  CURRENT  AND  FUTURE  OPERATIONS 

A  military  foree  using  network-eentrie  weapon  systems  would  see  the  greatest 
advantage  against  another  large,  eonventional  military  foree.  The  benefits  of  a  networked 
foree  allow  for  improvements  in  maneuver  and  eoneentration  of  fire  against  ground  units, 
ships,  and  aireraft.  It  provides  the  ultimate  expression  of  eonventional,  state-on-state, 
third-generation  warfare. 

The  military  eonfiiets  eurrently  faeing  the  United  States  and  its  allies  do  not 
eonform  to  the  type  of  eombat  that  benefits  from  network-eentrie  weapon  systems. 
Rather,  the  missions  in  Iraq  and  Afghanistan  resemble  the  eounterinsurgeney  and  fourth- 
generation  models  of  asymmetrie  warfare  and  politieal  stabilization  (Lind  et  al.  1989). 
These  eonfiiets  feature  non-state  aetors,  widely  dispersed  forees,  and  a  blurred  line 
between  eombatants  and  non-eombatants.  The  soeial,  eultural,  politieal,  and  eeonomie 
faetors  that  dominate  these  situations  derive  little  benefit  from  an  inereasingly  effeetive 
eonventional  military  foree — a  foree  that  laeks  a  proper  enemy  to  engage. 

If  the  United  States  will  primarily  experienee  this  uneonventional  type  of  warfare 
for  the  near  future,  an  aggressive  investment  in  network-eentrie  weapon  systems  may  be 
misplaeed.  On  the  other  hand,  a  robust  network  eould  serve  as  a  foree  multiplier  and 
allow  a  smaller  eonventional  foree  to  provide  eontinuing  deterrenee  against  a  large, 
eonventional  attaek  while  the  remainder  of  the  foree  eoneentrates  on  uneonventional 
missions.  The  natural  life-eyele  progression  of  weapon  systems  provides  opportunities  to 
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add  network-centric  characteristics  and  capabilities  in  an  incremental  manner,  providing 
opportunities  for  user  feedback  and  for  learning  from  early  experimentation. 

The  nascent  network-centric  capabilities  used  during  Operation  Enduring 
Freedom  and  Operation  Iraqi  Freedom  have  provided  an  opportunity  for  experimentation 
in  an  operational  environment  as  well  as  a  glimpse  of  their  potential.  Commanders 
praised  the  ability  to  track  friendly  forces  and  the  greater  efficiency  of  air  operations  due 
to  the  situational  awareness  provided  by  data  links  (Office  of  Force  Transformation  2005, 
17).  In  these  situations,  however,  the  enemy  lacked  the  ability  to  threaten  the  security  of 
the  network.  Security,  therefore,  has  not  been  tested.  Conflict  with  a  major  power 
capable  of  sophisticated  information  warfare  would  probably  include  a  major  attack  on 
all  aspects  of  system  security.  Developers,  therefore,  must  not  conclude  that  the  lack  of 
security  problems  to  date  indicates  the  lack  of  threats  or  vulnerabilities  that  may  manifest 
themselves  in  the  future. 

The  move  away  from  large-scale,  conventional  warfare  has  already  manifested 
itself  in  recent  changes  to  the  FCS.  First,  the  Army  canceled  the  manned  ground  vehicle 
portion  of  FCS.  Then,  in  May  2009,  it  changed  the  program  to  a  successor  program 
called  Army  Brigade  Combat  Team  Modernization.  This  new  effort  will  continue  many 
of  the  concepts  from  FCS,  but  will  deliver  them  over  a  longer  time  period  as  a  gradual 
force  modernization.  As  Ben  Friedman,  a  research  fellow  at  the  CATO  Institute 
commented. 

It  will  be  better  for  the  ground  forces  to  have  FCS  broken  up. 
Conventional  insurgencies  turn  out  to  be  situations  where  you  want  heavy 
vehicles.  We  don’t  need  to  get  there  that  fast;  you  can  get  to  theater  on 
sealift.  It  is  probably  good  that  the  Pentagon  is  adjusting  to  realities  that 
turn  out  to  be  different.  (Osborne  2009) 

Despite  these  recent  cuts,  however,  the  Army  still  plans  to  create  the  tactical  network 
envisioned  for  FCS  and  use  it  with  the  upgraded  forces  as  they  are  deployed  (Osborne 
2009).  The  pace  may  have  slowed,  but  the  march  toward  a  network-centric  force 
continues  as  the  services  plan  to  gradually  add  more  networking  capabilities  and 
network-centric  tactics. 
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The  future  development  and  deployment  of  network-eentric  weapon  systems 
depends  largely  on  the  enabling  eommunications  teehnology  that  gives  disparate  units  the 
ability  to  share  information.  One  example  of  this  enabling  teehnology  is  the  Joint 
Taotieal  Radio  System  (JTRS).  JTRS  promises  to  provide  this  eapability,  featuring  nine 
separate  waveforms  optimized  for  different  users  with  their  unique  needs  and  eonstraints. 
JTRS  radios  feature  a  modular  and  open-arehiteeture  design  with  most  funetionality 
provided  by  software.  This  design  allows  serviees  to  buy  eompatible  radios  and  use 
software  eonfiguration  to  optimize  the  funetions  to  the  partieular  mission  needs  (Carmana 
2009). 

B,  SUMMARY  OF  SECURITY  CONSIDERATIONS  FOR  NETWORK¬ 
CENTRIC  WEAPON  SYSTEMS 

Network-eentrie  weapon  systems  offer  the  prospeet  of  greater  effieieney  and 
effeetiveness  of  a  military  foree.  The  eombination  of  situational  awareness,  self- 
synehronization,  and  robustness  of  eommand  promises  to  help  a  smaller  force  operate 
with  the  power  of  a  much  larger  force  without  the  investment  and  risk  of  adding  more 
vehicles  and  personnel.  As  shown  in  this  thesis,  network-centric  weapon  systems  also 
introduce  the  critical,  strategic-level  risk  that  the  network  could  fall  victim  to  an 
asymmetric  attack.  Given  the  expertise  and  opportunity,  a  much  smaller  opposing  force 
might  discover  critical  information,  plant  false  data  into  friendly  networks,  and  shut  down 
the  network  entirely. 

Industry  experience  with  large-scale  computer  networks  shows  their  lack  of 
security  and  the  consequences  of  security-related  attacks.  Given  the  schedule  and  budget 
pressures  upon  the  defense  industry,  network-centric  systems  will  likely  use  commercial 
hardware,  software,  and  protocols  for  some  of  their  construction  (Camana  2009,  2-PM- 
28).  Therefore,  many  of  the  security  practices  seen  on  commercial  office-automation  and 
electronic  commerce  systems  carry  through  to  these  future  weapon  systems  and  their 
supporting  networks.  Unfortunately,  much  of  the  scholarship  on  hacking  and  computer 
security  focuses  on  technical  attacks  on  hardware  and  software  and  ignores  the  multi¬ 
faceted  systems  engineering  approach  necessary  to  protect  a  weapon  system. 
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The  overall  system-level  seeurity  of  a  network-centric  weapon  system  can  be 
described  as  a  combination  of  network  and  computer  security,  information  security, 
physical  security,  operational  security,  and  personnel  security.  Each  aspect  brings  unique 
dangers  and  protection  methods  that  must  be  considered  in  the  larger  context  of  the 
military  operation.  A  military  adversary  will  seek  the  most  efficient  means  to  weaken  the 
advantage  provided  by  the  network,  so  developers  must  seek  the  systems  perspective  and 
guard  against  the  most  efficient  attacks.  No  computer  system,  and  certainly  not  one  as 
complex  as  a  tactical  military  network,  can  be  completely  safe  against  all  attacks  on 
confidentiality,  integrity,  and  availability,  but  the  efficient  and  comprehensive  protection 
of  the  network  and  all  its  components  may  stave  off  a  compromise  long  enough  for 
friendly  forces  to  achieve  their  objectives. 

The  systems  engineering  approach  to  security  applies  throughout  the  system  life 
cycle  to  program  managers,  developers,  commanders,  operators,  and  maintainers.  At 
each  stage,  all  these  stakeholders  should  recall  the  importance  of  security  and  the 
consequences  of  attacks  on  confidentiality,  integrity,  and  availability.  They  must 
maintain  the  systems  engineering  approach  and  consider  the  possible  consequences  to  the 
larger  system  rather  than  focusing  exclusively  on  their  own  area  of  specialization. 
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